Тэмдэглэл: Энэ болон дараагийн хоёр лекц нь харилцааны мэдээллийн сангийн онолд зориулагдсан болно. Өгөгдлийн сангийн зохион байгуулалтын бүх харилцааны хандлага нь зөвхөн практик шинж чанартай байдаг тул энэ онол нь голчлон прагматик шинж чанартай байдаг. Харилцааны өгөгдлийн сангийн онолын шийдвэрлэхийг зорьж буй гол асуудал бол өгөгдлийн сангийн тодорхой схемийн ашигтай шинж чанарыг олж илрүүлэх, ийм схемийг бүтээх арга замыг боловсруулах явдал юм. Энэ асуудлыг ихэвчлэн харилцааны мэдээллийн сангийн дизайны асуудал гэж товчхон нэрлэдэг.

Оршил

Практик чиг баримжаатай хэдий ч, харилцааны мэдээллийн сангийн онолнь олон алдартай судлаачид ажиллаж байсан (үргэлжлүүлэн ажиллаж байгаа) бие даасан шинжлэх ухааны салбар юм. Бид энэ хичээлээр тухайн салбарт гарсан гол үр дүнг дэлгэрэнгүй тайлбарлахаар төлөвлөөгүй. Бидний зорилго бол үйл явцын ерөнхий ойлголтод шаардлагатай тодорхойлолт, мэдэгдлийг өгөх явдал юм харилцааны мэдээллийн сангийн дизайнхэвийн болгоход үндэслэсэн.

Практик талаасаа харилцааны мэдээллийн сангийн хамгийн чухал шинж чанарууд нь үзэл баримтлалд суурилдаг функциональ хамаарал, бид тусад нь лекцэнд холбогдох онолын асуудлуудын товч яриаг орууллаа. Эдгээр асуултуудын дунд хаалт болон функциональ хамаарлын багцыг хамарна, Армстронгийн аксиомуудхангалттай нөхцөлийн тухай Хитийн теорем алдагдалгүй харилцааны задрал. Энэхүү лекцийн үзэл баримтлал, мэдэгдэл нь 7-р лекцийн материалыг эзэмшихэд зайлшгүй шаардлагатай боловч бид энэ нь юу болохыг энгийн жишээгээр уншигчдад харуулахыг хичээсэн. харилцааны мэдээллийн сангийн онол, түүний нарийн төвөгтэй байдлын түвшин ямар байдаг, хэр зэрэг мэдрэмжтэй байдаг.

Үүнтэй холбоотой онолын материалыг бид салгаагүй гэдгийг анхаарна уу олон утгат хамааралТэгээд холболтын хамаарал. Үүнийг хоёр шалтгаанаар хийсэн. Нэгдүгээрт, эдгээр төрлийн хамаарал нь загварчлалд бага тохиолддог сэдвийн хэсэгмэдээллийн санг ашиглах. Тиймээс бид 8-р лекцийн хүрээнд зөвхөн холбогдох онолын материалын үндсийг танилцуулахад хангалттай гэж үзсэн. Хоёрдугаарт, онол хэдий ч олон утгат хамааралТэгээд холболтын хамаарал, үнэндээ онолоос илүү төвөгтэй биш юм функциональ хамаарал, түүний тодорхойлолт, мэдэгдэл нь энэ хичээлд хэтэрхий төвөгтэй байна.

Функциональ хамаарал

Практик талаасаа хамгийн чухал нь харилцааны ердийн хэлбэрүүдсуурь дээр суурилдаг харилцааны мэдээллийн сангийн онолуудүзэл баримтлал функциональ хамаарал. Цаашид танилцуулахын тулд бидэнд хэд хэдэн тодорхойлолт, мэдэгдэл хэрэгтэй болно (бид цааш нь тайлбарлаж, харуулах болно).

Ерөнхий тодорхойлолтууд

Өгчихье харилцааны хувьсагч r , мөн X ба Y нь r толгой хэсгийн дурын дэд олонлогууд ("нийлмэл" шинж чанарууд).

Утгын хувьд харилцааны хувьсагч r Y шинж чанар нь X шинж чанараас функциональ хамааралтай байдагхэрэв X-ийн утга бүр Y-ийн яг нэг утгатай тохирч байвал. Энэ тохиолдолд X шинж чанар гэж бас хэлдэг функциональ байдлаар тодорхойлдогшинж чанар Y (X нь тодорхойлогч ( тодорхойлогч) Y-ийн хувьд, Y нь X-ээс хамаарна). Бид үүнийг r.X->r.Y гэж тэмдэглэнэ.

Жишээлбэл, бид хамаарлыг ашиглах болно АЖИЛТНЫ_ТӨСӨЛ (SLUN_NAME, SLU_NAME, SLU_ZARP, PRO_NOM, PROJECT_RUK)(Зураг 6.1). Мэдээжийн хэрэг, хэрэв SLU_NOM бол харилцааны гол түлхүүрАЖИЛТНУУД, тэгвэл энэ харилцааны хувьд шударга байна функциональ хамаарал (FD) SLN_NAME->SERV_NAME.

Үнэн хэрэгтээ, харилцааны биеийн хувьд АЖИЛТНЫ_ТӨСӨЛЗурагт үзүүлсэн хэлбэрээр. 6.1-д дараахь FD (1)-ийг мөн гүйцэтгэнэ.

Цагаан будаа. 6.1.

SLUN_NOM->SLUN_NAME SLUN_NOM->SLUN_ZARP SLU_NOM->PRO_NOM SLUN_NOM->PROJECT_RUK (SLUN_NAME, SLU_NAME)->SLUN_ZARP (SLUN_NAME, SLUN_NAME)->PRO_NOM (SLUN_NAME)(SLUN_NAME)... M ->PROJECT_RUK болон гэх мэт.

Бүх ажилчдын нэрс өөр өөр байдаг тул дараах FD (2) нь бас хангагдсан байна.

SERV_NAME->SERV_NAME SERV_NAME->SLU_ZARP SER_NAME->PRO_NAME гэх мэт.

Түүнээс гадна Зураг дээрх жишээний хувьд. 6.1 сэтгэл хангалуун ба FD (3):

SLU_ZARP->PRO_NOM

Гэсэн хэдий ч FD бүлгийн шинж чанар (1) нь FD бүлгийн (2) ба (3) шинж чанараас ялгаатай болохыг анхаарна уу. Ажилчдын таних дугаар үргэлж өөр байх ёстой гэж үзэх нь логик бөгөөд төсөл бүр зөвхөн нэг менежертэй байдаг. Тиймээс (1) бүлгийн FD нь аливаа хүчин төгөлдөр утгын хувьд үнэн байх ёстой харилцааны хувьсагч АЖИЛТНЫ_ТӨСӨЛгэж үзэж болно инвариантууд, эсвэл бүрэн бүтэн байдлын хязгаарлалтэнэ харилцааны хувьсагч.

Бүлгийн FD (2) нь бүх ажилчид өөр өөр нэртэй байдаг гэсэн энгийн таамаглал дээр суурилдаг. Энэ нь Зураг дээрх жишээний хувьд үнэн юм. 6.1, гэхдээ цаг хугацаа өнгөрөхөд FD бүлгүүд (2) ямар ч үнэ цэнэд сэтгэл хангалуун бус байх боломжтой. харилцааны хувьсагч АЖИЛТНЫ_ТӨСӨЛ.

Эцэст нь (3) бүлгийн FD нь өөр өөр төсөлд хамрагдсан хоёр ажилтан ижил цалин авдаггүй гэсэн маш ер бусын таамаглал дээр суурилдаг. Дахин хэлэхэд энэ таамаглал нь Зураг дээрх жишээний хувьд үнэн юм. 6.1, гэхдээ энэ нь санамсаргүй тохиолдол байх магадлалтай.

Ирээдүйд бид зөвхөн эдгээрийг л сонирхох болно функциональ хамаарал, энэ нь боломжит бүх утгын хувьд хангагдсан байх ёстой харилцааны хувьсагчид.

Хэрэв r харилцааны А атрибут нь боломжит түлхүүр бол энэ харилцааны аль ч B шинж чанарын хувьд энэ нь үргэлж байх болно гэдгийг анхаарна уу.

DELPHI 6 ОРЧИНД ХӨТӨЛБӨРҮҮЛЭХ

Өгөгдлийн сан. Word ашиглан тайлан үүсгэх.

Редакцийн болон хэвлэлийн зөвлөлөөс баталсан

их сургуулийг лабораторийн цех болгон

Воронеж 2004 он

UDC 681.3

Воробьев Е.И., Короткевич Д.Э.. Delphi 6 орчинд програмчлал: Лабораторийн семинар: 2-р хэсэг: Мэдээллийн сан. Word ашиглан тайлан үүсгэх. Дамжуулалт. Воронеж: Воронеж. муж технологи. Их сургууль, 2004. 107 х.

Лабораторийн семинарын хоёрдугаар хэсэгт “Өгөгдлийн санг зохион бүтээх, Word программ дээр тайлан үүсгэх, өндөр үзүүлэлттэй программ үүсгэх үед thread ашиглах” сэдвээр Delphi 6 орчинд програм бичих онол практикийн мэдээллийг авч үзнэ.

Энэхүү нийтлэл нь 230100 "Мэдээлэл зүй ба компьютерийн шинжлэх ухаан" чиглэл, 230104 "Компьютерийн тусламжтай дизайны систем", "Өндөр түвшний хэлээр програмчлал" гэсэн чиглэлээр дээд мэргэжлийн боловсролын улсын боловсролын стандартын шаардлагыг хангаж байна.

Хүснэгт 3. Ил. 19. Ном зүй: 7 гарчиг.

Шинжлэх ухааны редактор: Доктор Тех. шинжлэх ухаан, проф. Я.Э. Львович

Шүүмжлэгчид: Воронежийн ойн академийн компьютерийн шинжлэх ухааны тэнхим (тэнхимийн эрхлэгч, техникийн шинжлэх ухааны доктор, проф. В.Е. Межов);

Доктор Тех. шинжлэх ухаан, проф. О.Ю.Макаров

© Воробьев Е.И., Короткевич Д.Е., 2004 он

© Дизайн. Воронеж муж

Техникийн их сургууль, 2004 он

Оршил

Өгөгдлийн сангийн тухай ойлголт

Өгөгдлийн сан нь Delphi-ийн гол давуу тал гэж тооцогддог. Өгөгдлийн сантай ажиллах тусгай хэлүүд (MS Visual FoxPro гэх мэт) ч гэсэн энэ төрлийн програмын хувьд энгийн, програмчлалын хүч чадлаараа доогуур байдаг. Делфи бүх нарийн төвөгтэй байдлыг нууж, нэгэн зэрэг хамгийн их хүчийг өгдөг. Дельфид богино хугацаанд хэрэгжүүлэх боломжгүй ажил гэж хэзээ ч байгаагүй. Хамгийн гол нь энэ бүхэн маш тохиромжтой бөгөөд ойлгоход хялбар хэрэгждэг. Delphi дээр та нарийн төвөгтэй мэдээллийн сантай ч гэсэн нэг мөр кодгүйгээр энгийн програмуудыг үүсгэж болно. Энэхүү заавар нь орон нутгийн мэдээллийн сантай ажиллах арга техникийг эзэмших лабораторийн даалгавруудыг багтаасан болно.

Харилцааны мэдээллийн сангийн онол

Арван жилийн өмнө өгөгдлийн сангийн програмчлал маш хэцүү ажил байсан. Өнөө үед үүнийг төсөөлөхөд бэрх, учир нь Delphi-ийн ачаар програм бичих үйл явц хялбарчлагдсан бөгөөд мэдээллийн сангийн сортуудын тоо аль хэдийн хэдэн арван болж байна.

Мэдээллийн санг дотоод (хөтөлбөр ажилладаг үйлчлүүлэгчийн компьютер дээр суулгасан) болон алсын (серверт суулгасан, алсын компьютер) гэж хуваадаг. Серверийн мэдээллийн сан нь алсын компьютер дээр байрладаг бөгөөд серверийн програм хангамжийн хяналтан дор ажилладаг. Тэдний гол давуу талууд нь нэг мэдээллийн сантай хэд хэдэн хэрэглэгчид нэгэн зэрэг ажиллах боломжтой бөгөөд сүлжээнд хамгийн бага ачаалалтай байдаг. Мөн сүлжээнд хэт их ачаалал үүсгэдэг, программист болон эцсийн хэрэглэгчдэд ашиглахад тохиромжгүй сүлжээний мэдээллийн сангууд байдаг. Програм нь сүлжээний мэдээллийн санд холбогдох үед түүний бараг бүрэн хуулбарыг серверээс татаж авдаг. Хэрэв та өөрчлөлт хийсэн бол таны хуулбарыг буцааж бүрэн татаж авах болно. Энэ нь хэт их өгөгдөл дамжуулахаас болж сүлжээнд их хэмжээний ачаалал үүсгэдэг тул энэ нь маш тохиромжгүй юм. Клиент-сервер технологийн хувьд клиент програм нь зарим өгөгдлийг хүлээн авахын тулд сервер рүү энгийн текст хүсэлт илгээдэг. Сервер үүнийг боловсруулж, зөвхөн шаардлагатай хэсгийг буцаана. Зарим өгөгдлийг өөрчлөх шаардлагатай үед сервер рүү дахин хүсэлт илгээгдэж, сервер өгөгдлийн сан дахь өгөгдлийг өөрчилдөг. Тиймээс ихэвчлэн зөвхөн текст хүсэлтийг сүлжээгээр дамжуулдаг бөгөөд энэ нь ихэвчлэн нэг килобайтаас бага зай эзэлдэг. Бүх өгөгдлийг сервер боловсруулдаг бөгөөд энэ нь үйлчлүүлэгчийн машин бага ачаалалтай бөгөөд нөөцөд тийм ч их шаардлага тавьдаггүй гэсэн үг юм. Сервер нь үйлчлүүлэгч рүү зөвхөн хамгийн шаардлагатай өгөгдлийг илгээдэг бөгөөд энэ нь бүх мэдээллийн сангийн хуулбарыг шаардлагагүй татаж авахгүй гэсэн үг юм. Энэ бүхний ачаар сүлжээний мэдээллийн сан аль хэдийн хуучирсан бөгөөд бараг ашиглагдаагүй байна. Тэдгээрийг үйлчлүүлэгч-серверийн технологиор бараг бүрэн сольсон. Гэхдээ орон нутгийн мэдээллийн сан үргэлж амьдрах болно. Тэдгээрийн хадгалалтын формат өөрчлөгдөж эсвэл зарим шинэ функцүүд нэмэгдэж магадгүй ч мэдээллийн сан нь өөрсдөө байх болно. Цаашид авч үзэхийн тулд бид шинэ ойлголтыг тодорхойлох хэрэгтэй - ширээ. Одоохондоо зөвхөн ерөнхий зарчмууд яригдаж байгаа учраас ерөнхий ойлголтыг ашигласан мэдээллийн сан. Өгөгдлийн сангийн хүснэгт нь өгөгдлийг багананд байрлуулсан хоёр хэмжээст массивтай адил юм (хүснэгтийн гол жишээ бол Excel юм). Өгөгдлийн сан нь нэгээс хэд хэдэн хүснэгт хүртэл хадгалах боломжтой файл юм. Ихэнх локал мэдээллийн сан нь зөвхөн нэг хүснэгтийг (dBase, Paradox, XML) хадгалах боломжтой. Гэхдээ нэг файлд хэд хэдэн хүснэгт агуулагдсан орон нутгийн мэдээллийн сангийн төлөөлөгчид байдаг (жишээлбэл, Access).

Орон нутгийн мэдээллийн сан

Орон нутгийн мэдээллийн сангуудаас хамгийн түгээмэл нь харилцаа холбоог авч үзье. Харилцааны мэдээллийн сан гэж юу вэ? Энэ бол баганууд нь түүнд хадгалагдсан өгөгдлийн нэрс байх хүснэгт бөгөөд мөр бүр нь өгөгдлийг өөрөө хадгалдаг. Өгөгдлийн сангийн хүснэгт нь Excel-ийн хүснэгттэй төстэй (илүү нарийвчлалтай бол Excel нь өгөгдлөө мэдээллийн сангийн технологи дээр суурилсан хувийн форматаар хадгалдаг). Локал мэдээллийн сангийн хүснэгтүүдийг дотоод хатуу диск дээр хадгалах эсвэл файлын сервер дээрх сүлжээний драйв дээр төвлөрсөн байдлаар хадгалах боломжтой. Эдгээр файлуудыг бусад файлуудын нэгэн адил стандарт хэрэгслээр хуулж болно, учир нь өгөгдлийн сангийн хүснэгтүүд нь өөрөө тодорхой байршилд холбогддоггүй. Хамгийн гол нь програм нь хүснэгтийг олох боломжтой юм. Хүснэгт бүр мөрийг өвөрмөц байдлаар тодорхойлох нэг өвөрмөц талбартай байх ёстой. Энэ талбарыг түлхүүр талбар гэж нэрлэдэг. Эдгээр талбаруудыг хэд хэдэн хүснэгтийг хооронд нь холбоход ихэвчлэн ашигладаг. Гэхдээ хүснэгтэд хамааралгүй байсан ч гэсэн түлхүүр талбар шаардлагатай хэвээр байна. Тоон төрлийг түлхүүр болгон ашиглах нь зүйтэй бөгөөд хэрэв мэдээллийн сан зөвшөөрвөл "autoincrement" төрлийн (автоматаар нэмэгдэх/багарах тоо эсвэл тоолуур) байвал илүү дээр байх болно. Өгөгдлийн сангийн хүснэгт дэх баганын нэрс бас өвөрмөц байх ёстой, гэхдээ энэ тохиолдолд заавал тоон байх албагүй. Өвөрмөц, ойлгомжтой байвал тэднийг хүссэнээрээ дуудаж болно. Багана бүр (мэдээллийн сангийн талбар) тодорхой төрөлтэй байх ёстой. Төрөлүүдийн тоо, тэдгээрийн сортууд нь мэдээллийн сангийн төрлөөс хамаарна, жишээлбэл, dBASE формат (DBF өргөтгөлтэй файлууд) нь зөвхөн 6 төрлийг дэмждэг бөгөөд Paradox аль хэдийн 15 хүртэлх төрлийг дэмждэг. Өгөгдлийн санг нэг файлд хадгалах боломжтой (Хандалт ) эсвэл хэд хэдэн (Парадокс, dBase). Илүү нарийвчлалтай, хүснэгтийн өгөгдөл нь үргэлж нэг файлд хадгалагддаг боловч нэмэлт мэдээллийг тусдаа файлд байрлуулж болно. Нэмэлт мэдээлэлд индекс, хязгаарлалт эсвэл тодорхой талбаруудын анхдагч утгуудын жагсаалт багтаж болно. Хэрэв файлуудын дор хаяж нэг нь эвдэрсэн эсвэл устгагдсан бол өгөгдлийг засварлах боломжгүй болно.

Юу болов индексүүд? Ихэнх тохиолдолд хүснэгтийн өгөгдөлд ямар нэгэн өөрчлөлт ордог тул ямар нэгэн мөрийг засахын өмнө та үүнийг олох хэрэгтэй. Лавлах ном болгон ашигладаг статик хүснэгтүүд хүртэл хүссэн өгөгдлийг харуулахын өмнө хайлтын үйл ажиллагаа явуулдаг. Хайлт нь маш их цаг хугацаа шаардсан ажил юм, ялангуяа хүснэгтэд маш олон мөр байгаа бол. Индексүүд нь энэ процедурыг хурдасгахад чиглэгддэг бөгөөд тэдгээрийг эрэмбэлэх эхлэл болгон ашиглаж болно. Энэ үе шатанд индексжүүлээгүй талбарыг захиалах боломжгүй гэдгийг мэдэхэд хангалттай.

Хэрэв танд ширээ хэрэгтэй бол талбарт захиалга өгөх болно" Овог", дараа нь энэ талбарыг эхлээд индексжүүлэх ёстой. Дараа нь та хүснэгт одоо ийм ийм индекстэй ажиллах ёстойг зааж өгөх хэрэгтэй бөгөөд үүнийг автоматаар эрэмбэлэх болно.

Сайн зохион бүтээсэн мэдээллийн санд өгөгдлийн илүүдэл арилж, үл нийцэх өгөгдлийг хадгалах магадлалыг багасгадаг. Тиймээс мэдээллийн санг бий болгох нь өгөгдлийн илүүдлийг багасгах, найдвартай байдлыг нэмэгдүүлэх гэсэн хоёр үндсэн зорилготой.

Аливаа програм хангамжийн бүтээгдэхүүний амьдралын мөчлөг, түүний дотор мэдээллийн сангийн удирдлагын систем нь дизайн, хэрэгжүүлэх, ажиллуулах үе шатуудаас (ихэвчлэн) бүрддэг.

Мэдээжийн хэрэг, мэдээллийн сангийн хэрэглээний амьдралын мөчлөгийн хамгийн чухал хүчин зүйл бол дизайны үе шат юм. Системийн гүйцэтгэл, мэдээллийн баялаг, улмаар ашиглалтын хугацаа нь өгөгдлийн сангийн бүтцийг хэр анхааралтай бодож, түүний элементүүдийн хоорондын холболтыг хэр нарийн тодорхойлсоноос хамаарна.

Өгөгдлийн сангийн шаардлага

Тиймээс, сайн боловсруулсан мэдээллийн сан:

1. Өгөгдлийн сангийн контентын хэрэглэгчийн бүх шаардлагыг хангана. Өгөгдлийн сангийн дизайн хийхээс өмнө мэдээллийн сангийн функциональд тавигдах хэрэглэгчийн шаардлагын талаар өргөн хүрээтэй судалгаа хийх шаардлагатай.

2. Өгөгдлийн тууштай, бүрэн бүтэн байдлыг хангана. Хүснэгтийг зохиохдоо тэдгээрийн шинж чанарууд болон хэрэглэгчийн буруу утгыг оруулах боломжийг хязгаарлах зарим дүрмийг тодорхойлох шаардлагатай. Өгөгдлийг хүснэгтэд шууд бичихээс өмнө баталгаажуулахын тулд мэдээллийн сан нь өгөгдлийн загварын дүрмийг дуудаж, мэдээллийн бүрэн бүтэн байдлыг хангах ёстой.

3. Мэдээллийн жам ёсны, ойлгомжтой бүтэцтэй байдлыг хангана. Өгөгдлийн сангийн өндөр чанартай бүтэц нь мэдээллийн санд хандах хүсэлтийг илүү "ил тод", ойлгоход хялбар болгох боломжийг олгодог; Үүний үр дүнд буруу өгөгдөл оруулах магадлал буурч, мэдээллийн сангийн засвар үйлчилгээний чанар сайжирна.

4. Хэрэглэгчдийн мэдээллийн сангийн гүйцэтгэлийн шаардлагыг хангасан. Их хэмжээний мэдээлэлтэй, бүтээмжийг хадгалах асуудал

дизайны үе шатны бүх дутагдлыг нэн даруй "онцлон" гол үүрэг гүйцэтгэж эхэлнэ.

Дараахь цэгүүд нь мэдээллийн сангийн дизайны үндсэн үе шатуудыг илэрхийлнэ.

1. Мэдээллийн сангийн мэдээллийн хэрэгцээг тодорхойлох.

2. Өгөгдлийн санд загварчлах шаардлагатай бодит ертөнцийн объектуудад дүн шинжилгээ хийх. Эдгээр объектуудаас эдгээр аж ахуйн нэгжийн нэгж, шинж чанарыг (жишээлбэл, "хэсэг" нэгжийн хувьд шинж чанар нь "нэр", "өнгө", "жин" гэх мэт байж болно) бүрдүүлж, тэдгээрийн жагсаалтыг бүрдүүлнэ.

3. Сонгосон DBMS (Paradox, dBase, FoxPro, Access, Clipper, InterBase, Sybase, Informix, Oracle гэх мэт)-ийн тэмдэглэгээн дэх объектууд болон шинж чанарууд - хүснэгт, багана (талбар) -ыг тааруулна уу.

4. Объект бүрийг өвөрмөц байдлаар тодорхойлох шинж чанаруудыг тодорхойл.

5. Өгөгдлийн бүрэн бүтэн байдлыг бий болгож, хадгалах дүрмийг боловсруулах.

6. Объектуудын (хүснэгт ба багана) хоорондын холболтыг бий болгох, хүснэгтийг хэвийн болгох.

7. Мэдээллийн найдвартай байдлыг хангах, шаардлагатай бол мэдээллийн нууцлалыг хадгалах асуудлыг төлөвлөх.

Холбогдох мэдээлэл.

Харилцааны алгебр нь олонлогын онол дээр суурилдаг бөгөөд мэдээллийн сангийн логикийн үндэс болдог.
Би өгөгдлийн сан болон SQL-ийн бүтцийг дөнгөж судалж байх үед харилцааны алгебрийн талаар урьдчилж танилцсан нь цаашдын мэдлэгийг миний толгойд зөв оруулахад ихээхэн тусалсан бөгөөд би энэ нийтлэлийг үүнтэй адил үр дүнтэй болгохыг хичээх болно.

Тиймээс хэрэв та энэ чиглэлээр суралцах гэж байгаа эсвэл зүгээр л сонирхож байгаа бол муур дээр дарна уу.

Харилцааны мэдээллийн сан

Эхлээд бид бүх үйлдлийг гүйцэтгэх харилцааны мэдээллийн сангийн тухай ойлголтыг танилцуулъя.

Харилцааны мэдээллийн сан нь мэдээллийн санд хадгалагдах ёстой бүх мэдээллийг агуулсан харилцааны багц юм. Энэ тодорхойлолтод бид харилцаа гэдэг нэр томьёог сонирхож байгаа боловч одоохондоо бид үүнийг хатуу тодорхойлолтгүйгээр үлдээх болно.
Бүтээгдэхүүний хүснэгтийг илүү сайн төсөөлье.

БҮТЭЭГДЭХҮҮНүүдийн хүснэгт

ID	НЭР	КОМПАНИ	ҮНЭ
123	Күүки	Dark Side ХХК	190
156	Цай	Dark Side ХХК	60
235	Хан боргоцой	"Фрукты" ХК	100
623	Улаан лооль	OOO "Хүнсний ногоо"	130

Хүснэгт нь 4 мөрөөс бүрдэх ба хүснэгтийн нэг мөр нь харилцааны онолын багц юм. Эмх цэгцтэй хэлхээний багцыг хамаарал гэж нэрлэдэг.
Харилцааг тодорхойлохын өмнө өөр нэр томъёог танилцуулъя - домэйн. Хүснэгттэй холбоотой домэйнууд нь багана юм.

Тодорхой болгохын тулд бид одоо харилцааны хатуу тодорхойлолтыг танилцуулж байна.

N олонлогуудыг D1,D2, … өгье. Dn (домайнууд), эдгээр олонлог дээрх R хамаарал нь маягтын дараалсан N-түлгүүдийн багц юм. , энд d1 нь D1-д хамаарах гэх мэт. D1,D2,..Dn олонлогуудыг R харилцааны домэйн гэж нэрлэдэг.
Түлшний элемент бүр нь аль нэг домэйнд харгалзах шинж чанаруудын аль нэгийн утгыг илэрхийлдэг.

Харилцааны түлхүүрүүд

Холболтод тавигдах шаардлага бол бүх хэлхээ нь ялгаатай байх ёстой. Түлхүүрийг өвөрмөц байдлаар тодорхойлохын тулд үндсэн түлхүүр байдаг. Анхдагч түлхүүр нь атрибут буюу хамгийн бага тооны атрибутуудын багц бөгөөд энэ нь тодорхой tuple-г өвөрмөц байдлаар тодорхойлдог бөгөөд нэмэлт шинж чанар агуулаагүй болно.
Үүний утга нь анхдагч түлхүүрийн бүх шинж чанарууд нь тодорхой хэлхээг тодорхойлоход шаардлагатай бөгөөд хангалттай байх ёстой бөгөөд түлхүүрийн аль нэг шинж чанарыг орхигдуулах нь түүнийг танихад хангалтгүй болгоно.
Жишээлбэл, ийм хүснэгтэд түлхүүр нь эхний болон хоёр дахь баганын шинж чанаруудын хослол байх болно.

Жолооч нарын хүснэгт

Байгууллага хэд хэдэн жолоочтой байж болох бөгөөд жолоочийг өвөрмөц байдлаар тодорхойлохын тулд "Байгууллагын нэр" ба "Жолоочийн нэр" баганын утгыг хоёуланг нь шаарддаг болохыг харж болно. Ийм түлхүүрийг нийлмэл түлхүүр гэж нэрлэдэг.

Харьцангуй мэдээллийн санд хүснэгтүүд хоорондоо холбогдож, хоорондоо мастер болон дэд хүснэгт хэлбэрээр холбогддог. Үндсэн болон дэд хүснэгтүүдийн хоорондын холболтыг үндсэн хүснэгтийн үндсэн түлхүүр ба дэд хүснэгтийн гадаад түлхүүрээр дамжуулан гүйцэтгэдэг.
Гадаад түлхүүр нь үндсэн хүснэгтийн үндсэн түлхүүр болох атрибут буюу шинж чанаруудын багц юм.

Энэхүү бэлтгэл онол нь харилцааны алгебрийн үндсэн үйлдлүүдтэй танилцахад хангалттай байх болно.

Харилцааны алгебрийн үйлдлүүд

Харьцааны алгебрийн үндсэн 8 үйлдлийг Э.Кодд санал болгосон.

• Холбоо
• Уулзвар
• Хасах
• Декарт бүтээгдэхүүн
• Дээж
• Төсөл
• Нийлмэл
• Хэлтэс

Үйлдлүүдийн эхний хагас нь багц дээрх ижил үйлдлүүдтэй төстэй. Зарим үйлдлүүдийг бусад үйлдлээр илэрхийлж болно. Ихэнх үйлдлүүдийг жишээн дээр авч үзье.

Ойлгохын тулд харилцаан дээрх аливаа алгебрийн үйлдлийн үр дүн нь өөр харилцаа бөгөөд дараа нь бусад үйлдлүүдэд ашиглаж болно гэдгийг санах нь чухал юм.
Жишээнүүдэд хэрэг болох өөр нэг хүснэгтийг бүтээцгээе.

ХУДАЛДАГЧДЫН хүснэгт

ID	ХУДАЛДАГЧ
123	ООО "Дарт"
156	"Ведро" ХК
235	"Хүнсний ногооны зах" ХК
623	ХК "фирм"

Энэ хүснэгтийн ID нь PRODUCTS хүснэгтийн үндсэн түлхүүртэй холбоотой гадаад түлхүүр гэдгийг хүлээн зөвшөөрцгөөе.

Эхлээд хамгийн энгийн үйлдлийг авч үзье - харилцааны нэр. Үүний үр дүн нь ижил хамаарал байх болно, өөрөөр хэлбэл, БҮТЭЭГДЭХҮҮН үйлдлийг хийснээр бид БҮТЭЭГДЭХҮҮН харилцааны хуулбарыг хүлээн авах болно.

Төсөл

Проекц гэдэг нь харилцааны шинж чанаруудыг зөвхөн заасан домайнуудаас гаргаж авах, өөрөөр хэлбэл хүснэгтээс зөвхөн шаардлагатай багануудыг сонгох, хэрэв хэд хэдэн ижил багцуудыг олж авбал ийм хэлхээний зөвхөн нэг л тохиолдол үлдэх үйлдэл юм. үүссэн харилцаа.
Жишээ нь БҮТЭЭГДЭХҮҮН хүснэгтээс ID, PRICE гэсэн сонголтоор проекц хийцгээе.

Үйлдлийн синтакс:
π (ID, ҮНЭ) БҮТЭЭГДЭХҮҮН

Түүврийн нөхцөлд бид ямар ч Булийн илэрхийллийг ашиглаж болно. 90-ээс дээш үнэ, бүтээгдэхүүний ID 300-аас бага өөр сонголт хийцгээе:

σ(ҮНЭ>90^ID<300) PRODUCTS

Үржүүлэх

Үржүүлэх буюу декартын үржвэр нь хоёр харилцаанд хийгддэг үйл ажиллагаа бөгөөд үүний үр дүнд бид хоёр анхны харилцаанаас бүх домэйнтэй хамаарлыг олж авдаг. Эдгээр домэйн дэх залгуурууд нь анхны харилцааны бүх боломжит хослолууд байх болно. Энэ нь жишээгээр илүү тодорхой болно.

Бид БҮТЭЭГДЭХҮҮН болон БУДАГЧДЫН хүснэгтүүдийн декартын үржвэрийг олж авдаг.
Үйлдлийн синтакс:

БҮТЭЭГДЭХҮҮН × худалдагч
Эдгээр хоёр хүснэгт ижил ID домэйнтэй болохыг та анзаарах болно. Энэ тохиолдолд ижил нэртэй домайнуудыг доор үзүүлсэн шиг харгалзах харилцааны нэрээр угтдаг.
Товчхондоо бүрэн харьцааг биш, харин нөхцөлийн ID бүхий дээжийг үржүүлье<235

(ижил хэлхээг өнгөөр ​​тодруулсан)

PRODUCTS.ID	НЭР	КОМПАНИ	ҮНЭ	SELLERS.ID	ХУДАЛДАГЧ
123	Күүки	Dark Side ХХК	190	123	ООО "Дарт"
156	Цай	Dark Side ХХК	60	156	"Ведро" ХК
123	Күүки	Dark Side ХХК	190	156	"Ведро" ХК
156	Цай	Dark Side ХХК	60	123	ООО "Дарт"

Энэ үйлдлийг ашиглах жишээний хувьд 90-ээс доош үнээр худалдагчийг сонгох шаардлагатайг төсөөлөөд үз дээ. Бүтээгдэхүүн байхгүй бол эхлээд эхний хүснэгтээс бүтээгдэхүүний ID-г авч, дараа нь хоёр дахь хүснэгтээс эдгээр ID-г ашиглан шаардлагатай мэдээллийг авах шаардлагатай болно. ХУДАЛДАГЧИЙН нэрс, мөн бүтээгдэхүүнийг ашиглан дараах асуултууд байх болно.

π (БУДЛАГЧ) σ (RODUCTS.ID=SELLERS.ID ^ ҮНЭ<90) PRODUCTS × SELLERS

Энэ үйлдлийн үр дүнд бид дараах харьцааг олж авна.

ХУДАЛДАГЧ

"Ведро" ХК

Холболт ба байгалийн холболт

Нэгдэх үйлдэл нь проекцын үйлдлийн урвуу үйлдэл бөгөөд одоо байгаа хоёр харилцаанаас шинэ харилцаа үүсгэдэг. Эхний болон хоёр дахь харилцааны хэлхээг нэгтгэх замаар шинэ харилцааг олж авдаг бол заасан шинж чанаруудын утгууд давхцаж байгаа харилцаа холбоог нэгтгэдэг. Тодруулбал, хэрэв та БҮТЭЭГДЭХҮҮН болон ХУДАЛДАГЧдын харилцааг холбосон бол эдгээр шинж чанарууд нь ID домайнуудын шинж чанарууд юм.

Түүнчлэн, тодорхой болгохын тулд та хоёр үйлдлийн үр дүнд холболтыг төсөөлж болно. Эхлээд эх хүснэгтүүдийн үржвэрийг авч, дараа нь үүссэн хамаарлаас бид ижил домэйны шинж чанаруудын тэгш байдлын нөхцлөөр сонголт хийдэг. Энэ тохиолдолд нөхцөл нь PRODUCTS.ID болон SELLERS.ID-ийн тэгш байдал юм.

БҮТЭЭГДЭХҮҮН болон ХУДАЛДАГЧИД гэсэн харилцааг хооронд нь холбож, харилцаа тогтоохыг хичээцгээе.

PRODUCTS.ID	НЭР	КОМПАНИ	ҮНЭ	SELLERS.ID	ХУДАЛДАГЧ
123	Күүки	Dark Side ХХК	190	123	ООО "Дарт"
156	Цай	Dark Side ХХК	60	156	"Ведро" ХК
235	Хан боргоцой	"Фрукты" ХК	100	235	"Хүнсний ногооны зах" ХК
623	Улаан лооль	OOO "Хүнсний ногоо"	130	623	ХК "фирм"

Байгалийн нэгдэл нь ижил төстэй хамаарлыг хүлээн авдаг боловч хэрэв бид мэдээллийн санд зөв тохируулсан схемтэй бол (энэ тохиолдолд БҮТЭЭГДЭХҮҮНИЙ ID хүснэгтийн үндсэн түлхүүр нь SELLERS ID хүснэгтийн гадаад түлхүүртэй холбогдсон) үр дүнд үүссэн хамаарал нь дараахийг агуулна. зөвхөн нэг ID домэйн.

Үйлдлийн синтакс:
БҮТЭЭГДЭХҮҮН ⋈ Борлуулагчид;

Та энэ харьцааг олж авна:

PRODUCTS.ID	НЭР	КОМПАНИ	ҮНЭ	ХУДАЛДАГЧ
123	Күүки	Dark Side ХХК	190	ООО "Дарт"
156	Цай	Dark Side ХХК	60	"Ведро" ХК
235	Хан боргоцой	"Фрукты" ХК	100	"Хүнсний ногооны зах" ХК
623	Улаан лооль	OOO "Хүнсний ногоо"	130	ХК "фирм"

Уулзвар ба хасах.

Уулзварын үйл ажиллагааны үр дүн нь хоёр харилцаанд бүрэн багтсан залгууруудаас бүрдэх хамаарал болно.
Хасах үйлдлийн үр дүн нь хоёр дахь харьцааны биш харин эхний харилцааны багцуудаас бүрдэх хамаарал болно.
Эдгээр үйлдлүүд нь багц дээрх ижил үйлдлүүдтэй төстэй тул дэлгэрэнгүй тайлбарлах шаардлагагүй гэж бодож байна.

Мэдээллийн эх сурвалжууд

• Өгөгдлийн санг ашиглах, зохион бүтээх үндэс - V. M. Илюшечкин
• лекцийн курс Өгөгдлийн сангийн танилцуулга - Женнифер Видом, Стэнфордын их сургууль

Би үндэслэлтэй сэтгэгдэл бичсэнд талархах болно

Чухал зүйлсийн талаар товчхон.

Өгөгдлийн сангийн хэвийн байдал

Эхний хэвийн хэлбэр (1NF)

• давхардсан өгөгдлийн бүлэг байхгүй
• өгөгдлийн атомын баталгаатай (бүх өгөгдөл нь бие даасан, бие даасан).

Дээд түвшинд энэ нь үндсэн түлхүүр үүсгэх, дараа нь дахин давтагдах бүлгүүдийг шинэ хүснэгтүүд рүү шилжүүлэх, эдгээр хүснэгтийн үндсэн түлхүүрүүдийг үүсгэх гэх мэтээр хийгддэг. Нэмж дурдахад, багана нь нийлмэл мэдээлэл агуулсан бүх бүртгэлийг баганын өгөгдөл тус бүрд тусад нь мөр болгон хуваах ёстой.

Хоёр дахь хэвийн хэлбэр (2NF)

• Хүснэгт нь 1NF-ийн нөхцлийг хангаж байна
• багана бүр нь нэг хэсэг биш харин бүхэл бүтэн түлхүүрээс хамаарна.

Гурав дахь хэвийн хэлбэр (3NF)

• Хүснэгт нь 2NF-ийн нөхцлийг хангаж байна
• ямар ч багана нь үндсэн түлхүүрийн хэсэг биш баганаас хамаарахгүй
• үүсмэл өгөгдөл агуулаагүй болно

Практик ач холбогдол багатай бусад ердийн хэлбэрүүд:

Бойс-Коддын хэвийн хэлбэр

Сонголт 3NF. Нэр дэвшигчийн түлхүүрүүд олон давхцаж байгаа нөхцөл байдлыг шийдвэрлэхэд зориулагдсан. Үнэн хэрэгтээ, эрдэм шинжилгээний нийгэмлэгээс гадуур ямар ч логик үндэслэл байхгүй.

Дөрөв дэх хэвийн хэлбэр

Олон утгатай хамааралтай асуудлуудыг шийдвэрлэхэд зориулагдсан. Хэрэв 3NF болгон бууруулсан хүснэгтэд нийлмэл үндсэн түлхүүрийн нэг багана нь өөр нэг үндсэн түлхүүрийн баганаас хамааралтай бол ийм нөхцөл байдал үүсдэг.

Тав дахь хэвийн хэлбэр

Алдагдалтай, алдагдалгүй харилцааны задралтай ажиллахад ашигладаг. Энэ нь нэг харилцааг хэд хэдэн өөр харилцаанд хуваах боломжтой нөхцөл байдалд үүсдэг, гэхдээ үүний дараа бид үүнийг логикоор анхны хэлбэрт нь буцааж өгөх боломжгүй болно.

Зургаа дахь хэвийн хэлбэр (домайн түлхүүрийн хэвийн хэлбэр)

Мэдээллийн санд өөрчлөлт оруулах гажиг байхгүй эсэхийг баталгаажуулна. Бодит нөхцөлд энэ нь бараг боломжгүй юм.

Харилцаа.

Би нэг удаа эмэгтэйчүүдээс эрчүүд гэж сонссон
нэн даруй байгаа өрөөнөөс гарахыг хичээ
"Харилцаа" гэдэг үг сонсогдов.<...>амжилтын түлхүүр
харилцаа гэдэг нь хүн бүрийн үүргээ ухамсарлах явдал юм
Үүнтэй холбогдуулан дүрэм, хязгаарлалт,
энэ харилцаагаар ногдуулсан.
(C) Роберт Виера, "Мэргэжлийн SQL Server 2000 програмчлал"

Харилцааны төрлүүд

• Нэг нэгээр нь (тохируулах өгөгдлийг өөр өөр мэдээллийн санд хадгалах шаардлагатай эсвэл мөрийн өгөгдлийн дээд хэмжээ хэтэрсэн үед утга учиртай)
• Тэг эсвэл нэгээс нэг
• Нэгээс олон
• Нэгээс -тэг, -нэг эсвэл -олон
• Олон-олон (холболтын хүснэгтүүд)

Холбоонууд

ДОТООД НЭГДСЭН

Онцгой нэгдэл. Сонголтын үр дүнд зөвхөн өгөгдсөн нөхцлийн хосолсон хүснэгтэд таарч байгаа хүснэгтийн бичлэгүүд орно.

ЗҮҮН|БАРУУН НЭГДЭХ

Хамтарсан нэгдэх. Сонголтын үр дүнд хүснэгтээс зүүн/баруун талд байгаа бичлэгүүд орно НЭГДЭХтус тус. Энэ тохиолдолд дутуу "хосолсон" бичлэгийн өгөгдлийг бөглөнө NULL.
Зүүн_хүснэгтээс ЗҮҮН_Хүснэгтээс баруун_хүснэгт НЭГДСЭНЭ– зүүн хүснэгтийн бүх бичлэгүүд зүүн_хүснэгт багтсан болно
Зүүн_хүснэгтээс БАРУУН Баруун_хүснэгт НЭГДЭХ– баруун хүснэгтийн баруун_хүснэгтийн бүх бичлэгийг оруулсан болно

БҮТЭН НЭГДээрэй

Хамтарсан нэгдэх. Сонгон шалгаруулалтын үр дүнд зөвхөн нөгөө хүснэгтэд таарч байгаа бичлэгүүд төдийгүй нөгөө хүснэгтэд тохирох зүйл олдоогүй хоёр хүснэгтийн бичлэгүүд орно. Энэ тохиолдолд дутуу "хосолсон" бичлэгийн өгөгдлийг NULL-ээр дүүргэх болно.

CROSS NOIN

Хөндлөн холбоо (картезийн бүтээгдэхүүн). Нэг хүснэгтийн бичлэг бүрийг нөгөө хүснэгтийн бүх бичлэгтэй тааруулна. Үүссэн бичлэгийн тоо нь хоёр хүснэгтийн бичлэгийн тооны үржвэртэй тэнцүү байна.

Хэд хэдэн зохион байгуулах зарчим НЭГДЭХ-ийн

Хэрэв та хэд хэдэн хүснэгтэд нэгдэх шаардлагатай бол хоёр зарчмыг санах хэрэгтэй.

1. Зүүн талын бүх үйлдвэрчний эвлэлүүд НЭГДЭХасуулгад оруулах эсвэл хасах нэг хүснэгт гэж үздэг.
2. Бүх үйлдвэрчний эвлэлүүд ЗӨВ НЭГДЭХМөн асуулгад оруулах эсвэл хасахын тулд нэг хүснэгт гэж үздэг.

Эдгээр зарчмуудын үр дагавар нь цогц холбоог бий болгох дараах зөвлөмж юм.

• Боломжтой бол INNER JOIN-ийг ашиглах хэрэгтэй.
• OUTER JOIN-г ашиглах шаардлага гарвал хамгийн сүүлд, харин INNER JOIN-ийг холболтын эхэнд байрлуулна.

P.S. Дээр дурдсан бүхэн нь тодорхой DBMS-ийн онцлогтой холбоогүй, харилцааны мэдээллийн сангийн онолын ерөнхий "постолатууд" юм.

Өгөгдлийн загвар нь өгөгдлийн бүтэц, тэдгээрийг боловсруулах үйл ажиллагааны багц юм. Өгөгдлийн загварыг ашиглан та объектуудын бүтэц, тэдгээрийн хоорондын харилцааг нүдээр харуулах боломжтой. Өгөгдлийн загварын нэр томъёо нь "өгөгдлийн элемент" ба "заавал дагаж мөрдөх дүрэм" гэсэн ойлголтоор тодорхойлогддог. Өгөгдлийн элемент нь аливаа өгөгдлийн багцыг тайлбарлах ба холбооны дүрмүүд нь өгөгдлийн элементүүдийг хооронд нь холбох алгоритмуудыг тодорхойлдог. Өнөөдрийг хүртэл олон янзын өгөгдлийн загваруудыг боловсруулсан боловч практикт гурван үндсэн загварыг ашиглаж байна. Мэдээллийн шаталсан, сүлжээний болон харилцааны загварууд байдаг. Үүний дагуу тэд шаталсан, сүлжээний болон харилцааны DBMS-ийн талаар ярьдаг.

O Өгөгдлийн шаталсан загвар. Өдөр тутмын амьдралд шаталсан зохион байгуулалттай өгөгдөл маш түгээмэл байдаг. Тухайлбал, дээд боловсролын сургалтын байгууллагын бүтэц нь олон шатлалт шаталсан бүтэц юм. Шаталсан (мод) мэдээллийн сан нь эмх цэгцтэй элементүүдийн багцаас бүрдэнэ. Энэ загварт эхний элементүүд нь бусад элементүүдийг үүсгэдэг бөгөөд эдгээр элементүүд нь эргээд дараагийн элементүүдийг үүсгэдэг. Хүүхэд элемент бүр зөвхөн нэг эх элементтэй.

Байгууллагын бүтэц, материалын жагсаалт, номын агуулгын хүснэгт, төслийн төлөвлөгөө болон бусад олон өгөгдлийн багцыг шаталсан хэлбэрээр танилцуулж болно. Өвөг дээдэс ба үр удам хоорондын холбоосын бүрэн бүтэн байдал автоматаар хадгалагдана. Үндсэн дүрэм: ямар ч хүүхэд эцэг эхгүйгээр оршин тогтнох боломжгүй.

Энэ загварын гол сул тал нь дизайн хийх явцад мэдээллийн баазын үндэс болсон шатлалыг ашиглах хэрэгцээ юм. Мэдээллийг байнга өөрчлөн зохион байгуулах хэрэгцээ (мөн ихэнхдээ энэ өөрчлөн байгуулалтыг хийх боломжгүй байдаг) нь илүү ерөнхий загвар болох сүлжээний загварыг бий болгоход хүргэсэн.

O Сүлжээний өгөгдлийн загвар. Өгөгдлийн зохион байгуулалтын сүлжээний хандлага нь шаталсан аргын өргөтгөл юм. Энэ загвар нь шаталсан загвараас ялгаатай нь үүсгэсэн элемент бүр нэгээс олон үүсгэгч элементтэй байж болно. ■

Сүлжээний өгөгдлийн сан нь холбогдох байгууллагын өгөгдөлд хамаарах бүх төрлийн харилцааг шууд илэрхийлж чаддаг тул энэ өгөгдлийг янз бүрийн аргаар удирдаж, судалж, асууж болно, өөрөөр хэлбэл сүлжээний загвар нь зөвхөн нэг шатлалаар хязгаарлагдахгүй. Гэсэн хэдий ч сүлжээний мэдээллийн санд хүсэлт гаргахын тулд түүний бүтцийг гүнзгий судалж үзэх шаардлагатай (энэ мэдээллийн сангийн схемийг гартаа байлгах), мэдээллийн санд шилжих механизмыг боловсруулах нь энэхүү мэдээллийн сангийн загварын томоохон дутагдал юм. .

O Харилцааны өгөгдлийн загвар. Харилцааны өгөгдлийн загварын үндсэн санаа нь аливаа өгөгдлийн багцыг хоёр хэмжээст хүснэгт хэлбэрээр илэрхийлэх явдал юм. Хамгийн энгийн хэлбэрээр харьцах загвар нь нэг хоёр хэмжээст хүснэгтийг дүрсэлдэг боловч ихэнхдээ загвар нь хэд хэдэн өөр өөр хүснэгтүүдийн бүтэц, хамаарлыг тодорхойлдог.

Харилцааны өгөгдлийн загвар

Тэгэхээр мэдээллийн системийн зорилго нь боловсруулах явдал юм өгөгдөлтухай объектуудхаргалзан бодит ертөнц холболтуудобъектуудын хооронд. Өгөгдлийн сангийн онолд өгөгдлийг ихэвчлэн гэж нэрлэдэг шинж чанарууд баобъектууд - аж ахуйн нэгжүүд.Объект, шинж чанар, холболт нь I.S.-ийн үндсэн ойлголт юм.

Объект(эсвэл мөн чанар) нь байгаа зүйл ба ялгах боломжтой,өөрөөр хэлбэл, объектыг ижил төстэй нэг объектыг нөгөөгөөс нь ялгах нэр, арга зам бүхий "ямар нэгэн зүйл" гэж нэрлэж болно. Жишээлбэл, сургууль бүр объект юм. Объектууд нь мөн хүн, сургуулийн анги, компани, хайлш, химийн нэгдэл гэх мэт зүйл юм. Объектууд нь зөвхөн материаллаг объект төдийгүй бодит ертөнцийг тусгасан илүү хийсвэр ойлголт байж болно. Жишээлбэл, үйл явдал, бүс нутаг, урлагийн бүтээлүүд; ном (хэвлэмэл бүтээгдэхүүн биш, харин бүтээл хэлбэрээр), театрын тоглолт, кино; эрх зүйн хэм хэмжээ, философийн онол гэх мэт.

Атрибут(эсвэл өгсөн)- энэ нь тодорхой объектыг тодорхойлдог тодорхой үзүүлэлт бөгөөд тухайн объектын тодорхой жишээнд тодорхой тоо, текст эсвэл бусад утгыг авдаг. Мэдээллийн систем нь тухайн сэдвийн хүрээнд тусгайлан боловсруулсан объектуудын багцтай ажилладаг шинж чанарын утгуудтодорхой объектуудын (өгөгдөл). Жишээлбэл, сургуулийн хичээлийг объектын багц болгон авч үзье. Ангийн сурагчдын тоо нь тоон утгыг авдаг өгөгдөл юм (нэг анги 28, нөгөө анги нь 32). Ангийн нэр нь текстийн утгыг авдаг өгөгдсөн нэр юм (нэг нь 10А, нөгөө нь 9B гэх мэт).

Харилцааны мэдээллийн санг хөгжүүлэх ажил 60-аад оны сүүлээр эхэлсэн бөгөөд анхны бүтээлүүд гарч ирэх үед; Мэдээллийн санг зохион бүтээхдээ хүснэгтэн даталогийн загвар гэж нэрлэгддэг өгөгдлийг үзүүлэх танил, байгалийн аргуудыг ашиглах боломж.

Харилцааны мэдээллийн сангийн онолыг үндэслэгч нь 1970 оны 6-р сарын 6-нд нийтлэл хэвлүүлсэн IBM-ийн ажилтан доктор Э.Кодд гэж тооцогддог. Томоохон хуваалцсан мэдээллийн банкуудад зориулсан өгөгдлийн харилцааны загвар(Том хамтын мэдээллийн банкуудын харилцааны өгөгдлийн загвар). Энэ нийтлэл нь "харилцааны өгөгдлийн загвар" гэсэн нэр томъёог анх ашигласан. Доктор Э.Коддын 70-аад онд АНУ-д боловсруулсан харилцааны мэдээллийн сангийн онол нь өгөгдлийг үр дүнтэй зохион байгуулах дүрмийг тодорхойлсон хүчирхэг математик үндэслэлтэй юм. Э.Коддын боловсруулсан онолын хүрээ нь мэдээллийн сангийн дизайны онолыг хөгжүүлэх үндэс болсон.

Э.Кодд математикч мэргэжилтэй учир олонлогийн онолын төхөөрөмжийг (нэгдэл, огтлолцол, ялгаа, декарт үржвэр) өгөгдөл боловсруулахад ашиглахыг санал болгосон. Тэрээр аливаа өгөгдлийн багцыг математикт "харилцаа" гэж нэрлэдэг тусгай төрлийн хоёр хэмжээст хүснэгт хэлбэрээр илэрхийлж болохыг нотолсон.

ХарилцааныӨгөгдлийн сан нь бүх өгөгдлийг өгөгдлийн утгын тэгш өнцөгт хүснэгт хэлбэрээр хэрэглэгчдэд үзүүлэх бөгөөд мэдээллийн сан дээрх бүх үйлдлүүдийг хүснэгттэй ажиллахад хүргэдэг гэж үздэг.

Хүснэгтээс бүрдэнэ багана (талбар)Тэгээд мөр (бичлэг);өгөгдлийн санд өвөрмөц нэртэй байдаг. Хүснэгттусгасан Объектын төрөлбодит ертөнц (аж ахуйн нэгж),мөн түүний тус бүр string бол тодорхой объект юм.Хүснэгтийн багана бүр нь тухайн объектын тодорхой шинж чанарын утгуудын цуглуулга юм. Утга нь объектын шинж чанарын бүх боломжит утгуудын багцаас сонгогддог домэйн.

Хамгийн ерөнхий хэлбэрээр домэйн нь тухайн домэйны элементүүд хамаарах зарим үндсэн өгөгдлийн төрлийг зааж өгөх ба өгөгдлийн элементүүдэд дурын Boolean илэрхийлэлээр тодорхойлогддог. Хэрэв та өгөгдлийн зүйл дээр логикийн нөхцөлийг үнэлээд үр дүн нь үнэн бол тухайн зүйл домэйнд хамаарна. Хамгийн энгийн тохиолдолд домэйн нь ижил төрлийн боломжит утгын багц гэж тодорхойлогддог. Жишээлбэл, бүх ажилчдын төрсөн огнооны цуглуулга нь "төрсөн огнооны домэйн"-ыг, бүх ажилчдын нэрс нь "ажилтны нэрийн домэйн"-ыг бүрдүүлдэг. Төрсөн огнооны домэйн нь цаг хугацааны өгөгдлийн төрөлтэй байх ёстой бөгөөд ажилтны нэрийн домэйн тэмдэгтийн өгөгдлийн төрөлтэй байх ёстой.

Хэрэв хоёр утга нэг домэйноос ирсэн бол хоёр утгын хооронд харьцуулалт хийж болно. Жишээлбэл, хэрэв төрсөн огнооны домэйноос хоёр утгыг авсан бол та тэдгээрийг харьцуулж, аль ажилтан ахмад болохыг тодорхойлох боломжтой. Хэрэв утгуудыг өөр өөр домэйноос авсан бол тэдгээрийг харьцуулахыг зөвшөөрөхгүй, учир нь энэ нь ямар ч утгагүй юм. Жишээлбэл, ажилтны нэр, төрсөн огноог харьцуулж үзэхэд тодорхой зүйл гарахгүй.

Багана бүр (талбар) нэртэй байдаг бөгөөд энэ нь ихэвчлэн хүснэгтийн дээд талд бичигддэг. Тодорхой DBMS доторх хүснэгтүүдийг зохиохдоо талбар тус бүрээр нь сонгох боломжтой төрөл,өөрөөр хэлбэл, түүнийг харуулах дүрмийн багцыг тодорхойлох, түүнчлэн энэ талбарт хадгалагдсан өгөгдөл дээр хийж болох үйлдлүүдийг тодорхойлох. Төрөл бүрийн багц нь өөр өөр DBMS-ийн хооронд өөр өөр байж болно.

Талбарын нэр нь хүснэгтэд өвөрмөц байх ёстой, гэхдээ өөр өөр хүснэгтүүд ижил нэртэй талбаруудтай байж болно. Аливаа хүснэгт дор хаяж нэг талбартай байх ёстой; Талбарууд нь тэдгээрийг үүсгэх үед тэдгээрийн нэр гарч ирсэн дарааллын дагуу хүснэгтэд байрлана. Талбаруудаас ялгаатай нь мөрүүд нь нэргүй; Хүснэгт дэх тэдгээрийн дараалал тодорхойлогдоогүй бөгөөд тэдгээрийн тоо логикийн хувьд хязгааргүй байдаг.

Хүснэгт дэх мөрүүд эрэмблэгдээгүй тул байрлалаар нь мөр сонгох боломжгүй - тэдгээрийн дунд "эхний", "хоёр дахь", "сүүлийн" гэсэн зүйл байхгүй. Аливаа хүснэгтэд нэг буюу хэд хэдэн багана байдаг бөгөөд тэдгээрийн утгууд нь мөр бүрийг өвөрмөц байдлаар тодорхойлдог. Ийм багана (эсвэл баганын хослол) гэж нэрлэдэг үндсэн түлхүүр. Хиймэл талбарыг ихэвчлэн хүснэгтийн дугаарын бүртгэлд нэвтрүүлдэг. Жишээлбэл, ийм талбар нь түүний дарааллын талбар байж болох бөгөөд энэ нь хүснэгтийн бичлэг бүрийн өвөрмөц байдлыг баталгаажуулж чадна. Түлхүүр нь дараах шинж чанартай байх ёстой.

Өвөрмөц байдал.Ямар ч үед түлхүүрт орсон шинж чанаруудын хослолын хувьд ижил утгатай хоёр өөр харилцааны хэлхээ байхгүй. Өөрөөр хэлбэл, хүснэгтэд ижил таних дугаар эсвэл паспортын дугаартай хоёр мөр байж болохгүй.

Минимализм.Түлхүүрт орсон шинж чанаруудын аль нь ч өвөрмөц байдлыг зөрчихгүйгээр түлхүүрээс хасагдах боломжгүй. Энэ нь та паспортын дугаар болон таних дугаарыг хоёуланг нь агуулсан түлхүүр үүсгэх ёсгүй гэсэн үг юм. Түлхүүрийг өвөрмөц байдлаар тодорхойлохын тулд эдгээр шинж чанаруудын аль нэгийг ашиглахад хангалттай. Та мөн түлхүүрт өвөрмөц бус шинж чанарыг оруулах ёсгүй, өөрөөр хэлбэл таних дугаар болон ажилтны нэрийг хослуулан түлхүүр болгон ашиглахыг хориглоно. Түлхүүрээс ажилтны нэрийг хассанаар мөр бүрийг өвөрмөц байдлаар тодорхойлж болно.

Харилцаа бүр дор хаяж нэг боломжит түлхүүртэй байдаг, учир нь түүний бүх шинж чанарууд нь өвөрмөц байдлын нөхцлийг хангадаг - энэ нь харилцааны тодорхойлолтоос л гардаг.

Боломжит түлхүүрүүдийн нэг нь санамсаргүй байдлаар сонгогддог үндсэн түлхүүр болгон.Үлдсэн боломжит түлхүүрүүдийг хэрэв байгаа бол гэж авна өөр түлхүүрүүд.Жишээлбэл, хэрэв та таних дугаарыг үндсэн түлхүүрээр сонговол паспортын дугаар нь өөр түлхүүр болно.

Хүснэгтүүдийн хамаарал нь харилцааны өгөгдлийн загварын хамгийн чухал элемент юм. Үүнийг дэмжиж байна гадаад түлхүүрүүд.

Харилцааны өгөгдлийн сангийн загварыг тайлбарлахдаа тодорхойлолтын түвшин (онол эсвэл практик) болон системээс (Access, SQL Server, dBase) хамааран ижил ойлголтод өөр өөр нэр томъёог ихэвчлэн ашигладаг. Хүснэгтэнд 2.3-д ашигласан нэр томъёоны хураангуйг оруулсан болно.

Хүснэгт 2.3.Өгөгдлийн сангийн нэр томъёо

Өгөгдлийн сангийн онол____________ Харилцааны мэдээллийн сан_________ SQL Server __________

Харилцааны хүснэгт

Tuple Бичлэгийн мөр

AttributeField_______________Багана

Харилцааны мэдээллийн сан

Харилцааны мэдээллийн санмэдээллийн санд заавал хадгалагдах бүх мэдээллийг агуулсан харилцааны багц юм. Өөрөөр хэлбэл, мэдээллийн сан нь бүх өгөгдлийг хадгалахад шаардлагатай хүснэгтүүдийн багцыг төлөөлдөг. Харьцангуй мэдээллийн сангийн хүснэгтүүд нь хоорондоо логик холбоотой байдаг.Харилцааны мэдээллийн санг зохион бүтээхэд тавигдах шаардлагыг ерөнхийд нь хэд хэдэн дүрэм болгон багасгаж болно.

О Хүснэгт бүр мэдээллийн санд өвөрмөц нэртэй байх ба ижил төрлийн мөрүүдээс бүрдэнэ.

O Хүснэгт бүр нь тогтмол тооны багана, утгуудаас бүрдэнэ. Нэг мөр баганад нэгээс олон утгыг хадгалах боломжгүй. Жишээлбэл, зохиогчийн тухай мэдээлэл, хэвлэгдсэн огноо, эргэлт гэх мэт хүснэгт байгаа бол зохиогчийн нэр бүхий баганад нэгээс илүү овог нэр хадгалах боломжгүй. Хэрэв номыг хоёр ба түүнээс дээш зохиолч бичсэн бол нэмэлт хүснэгт ашиглах шаардлагатай болно.

O Хүснэгтэд бие биенээ давхардсан хоёр мөр ямар ч үед байхгүй болно. Хүснэгтийн аль нэг мөрийг өвөрмөц байдлаар тодорхойлохын тулд мөрүүд дор хаяж нэг утгаараа ялгаатай байх ёстой.

О Хүснэгт дотор багана бүрт өвөрмөц нэр өгөгдсөн; Энэ баганад нэгэн төрлийн утгыг (огноо, овог нэр, утасны дугаар, мөнгөн дүн гэх мэт) байрлуулахын тулд тодорхой өгөгдлийн төрлийг тохируулсан болно.

O Өгөгдлийн сангийн бүрэн мэдээллийн агуулгыг өгөгдлийн тодорхой утгуудаар төлөөлдөг бөгөөд энэ нь дүрслэх цорын ганц арга юм. Жишээлбэл, хүснэгтүүдийн хоорондын хамаарал нь харилцааг зохиомлоор тодорхойлсон ямар ч заагч дээр биш, харгалзах баганад хадгалагдсан өгөгдөл дээр суурилдаг.

О Өгөгдлийг боловсруулахдаа хүснэгтийн аль ч мөр, баганад чөлөөтэй хандаж болно. Хүснэгтэд хадгалагдсан утгууд нь өгөгдөлд хандах дараалалд ямар ч хязгаарлалт тавьдаггүй. Баганын тайлбар,