КомпјутериБази на податоци

Базите на податоци се релациони. Концептот на релациона база на податоци

Доаѓањето на компјутерската технологија во наше време означи информативна револуција во сите сфери на човековата активност. Но, со цел да се осигура дека сите информации не станат непотребни ѓубре во глобалниот Интернет, беше измислен систем на бази на податоци во кој материјал е сортиран и систематизиран, поради што тие лесно се наоѓаат и се поднесуваат до подоцнежна обработка. Постојат три главни типови - алоцирајте ги базите на податоци релациони, хиерархиски, мрежа.

Основни модели

Враќајќи се во потеклото на бази на податоци, вреди да се каже дека овој процес е доста сложен, тој потекнува од развојот на програмабилна опрема за обработка на информации. Затоа, не е изненадувачки што бројот на нивните модели во моментов е повеќе од 50, но главните се хиерархиски, релациони и мрежни, кои сеуште се користат во пракса. Што се тие?

Хиерархиската база на податоци има структура на дрво и е составена од податоци од различни нивоа, меѓу кои има и врски. Мрежниот модел на базата на податоци е посложени дефиниција. Неговата структура наликува на хиерархиска структура, а шемата е проширена и рафинирана. Разликата меѓу нив е дека наследни податоци на хиерархискиот модел можат да бидат поврзани само со еден предок, а мрежата може да има неколку. Структурата на релациона база на податоци е многу посложена. Затоа, треба да се расклопи подетално.

Основниот концепт на релациона база на податоци

Овој модел беше развиен во 1970-тите од страна на д-р Едгар Кодд. Тоа е логично структурирана табела со полиња кои ги опишуваат податоците, нивните односи меѓу себе, операциите кои се извршуваат на нив, и што е најважно правилата кои го гарантираат нивниот интегритет. Зошто моделот се нарекува релациони? Се базира на односите (од латинскиот релатион) помеѓу податоците. Постојат многу дефиниции за овој тип на база на податоци. Релационите табели со информации се многу полесно да се организираат и да се дадат на обработка, наместо во мрежа или хиерархиски модел. Како може да се направи ова? Доволно е да се знаат особините, структурата на моделот и својствата на релационите маси.

Процесот на моделирање и компонирање на основните елементи

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

Моделирање табели и дизајнирање релациони бази на податоци се врши преку бесплатни алатки, како што се Workbench, PhpMyAdmin, Case Studio, dbForge Studio. По детален дизајн, треба да го зачувате графички подготвениот релациски модел и да го преведете во готовиот SQL-код. Во оваа фаза, можете да започнете со работа со сортирање, обработка и систематизација на податоци.

Карактеристики, структура и термини поврзани со релациониот модел

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

  • Релациона етикета = ентитет;
  • Распоред = атрибути = имиња на полето = назив на колоните на ентитетот;
  • Ентитет пример = tuple = рекорд = ред на етикетата;
  • Атрибута вредност = ентитет ќелија = поле.

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

  1. Суштината. Табелата на релациона база на податоци може да биде една, и може да биде цела група на табели што ги карактеризираат опишаните објекти благодарение на податоците складирани во нив. Тие имаат фиксен број на полиња и променлив број на записи. Табелата со модели на релациона база на податоци е составена од редови, атрибути и распоред.
  2. Евиденција е променлив број на редови кои прикажуваат податоци што го карактеризираат опишаниот објект. Евиденцијата се нумерира автоматски од страна на системот.
  3. Атрибути се податоци кои покажуваат опис на колоните на ентитетот.
  4. Поле. Претставува ентитет колона. Нивниот број е фиксна вредност која е поставена кога табелата е креирана или изменета.

Сега, знаејќи ги составните елементи на табелата, можете да отидете на својствата на базата на податоци за релациони модели:

  • Ентитетите на релационата ДБ се дводимензионални. Поради ова својство со нив, лесно е да се прават различни логички и математички операции.
  • Редоследот на вредностите на атрибутите и записите во релациона табела може да биде произволен.
  • Колоната во една релациона табела мора да има свое сопствено индивидуално име.
  • Сите податоци во колоната на ентитетот имаат фиксна должина и ист тип.
  • Секое внесување во суштина се смета за една ставка на податоци.
  • Конститутивните компоненти на линиите се уникатни во нивниот вид. Не постојат идентични редови во релациониот ентитет.

Врз основа на својствата на релациона DBMS, јасно е дека вредностите на атрибутот мора да бидат од ист тип, должина. Да ги разгледаме особините на вредностите на атрибутите.

Главните карактеристики на полињата на релациона база на податоци

Имињата на полињата мора да бидат уникатни во рамките на еден ентитет. Типовите на атрибути или полињата на релациона база на податоци опишуваат кои категории на податоци се зачувани во полето на ентитетот. Полето за релациона база на податоци мора да има фиксна големина, сметано со знаци. Параметрите и формата на вредностите на атрибутот го одредуваат начинот на кој ги корегираат податоците. Сепак постои таков концепт, како "маска", или "образец за внесување". Таа има за цел да ја дефинира конфигурацијата на внесување на податоци во вредноста на атрибутот. Неопходно е да се пријави грешка во полето кога е напишан неточен тип на податок . Исто така, одредени ограничувања се наметнуваат на елементите на полето - условите за проверка на точноста и точноста на внесувањето на податоците. Постои одредена задолжителна вредност на атрибутот, кој мора да биде недвосмислено пополнет со податоци. Некои атрибутни линии можат да бидат пополнети со вредности NULL. Дозволено е да внесете празни податоци во атрибути на поле. Како и известувањето за грешка, постојат вредности кои автоматски се пополнуваат од системот - ова се стандардните податоци. За да се забрза пребарувањето за какви било податоци, наменето е индексирано поле.

Дво-димензионална шема за релациона база на податоци

Схема на релациона база на податоци
Име на атрибутот 1 Име на атрибутот 2 Име на атрибутот 3 Име на атрибутот 4 Име на атрибутот 5
Element_1_1 Element_1_2 Element_1_3 Element_1_4 Element_1_5
Element_2_1 Element_2_2 Element_2_3 Element_2_4 Element_2_5
Element_3_1 Element_3_2 Element_3_3 Element_3_4 Element_3_5

За детално разбирање на моделот на систем за управување со користење на SQL, најдобро е да се разгледа шема користејќи пример. Ние веќе знаеме што е релациона база на податоци. Евиденцијата во секоја табела е една точка на податоци. За да се спречи вишок на податоци, потребно е да се извршат операции за нормализација.

Основни правила за нормализирање на релациониот ентитет

1. Вредноста на името на полето за релациона табела мора да биде единствена, единствена (првата нормална форма е 1NF).

2. За табела која веќе е намалена на 1НФ, името на секоја колона која не се идентификува треба да зависи од единствениот идентификатор на табелата (2NF).

3. За целата маса, која е веќе во 2NF, секое неидентификувано поле не може да зависи од елементот на друга неидентификувана вредност (3NF лице).

Бази на податоци: релациони односи помеѓу табели

Постојат два главни типа на односи помеѓу релациона табели:

  • «Еден-многу». Се појавува кога еден клучен запис од Табела # 1 се совпаѓа со неколку примери на вториот ентитет. Клучната икона на едниот крај од линијата покажува дека ентитетот е на "една" страна, вториот крај на линијата често се означува со симбол на бесконечност.

  • "Мулти-многу" односи се формира кога постои очигледна логичка интеракција помеѓу неколку реда на еден ентитет со ред записи во друга табела.
  • Ако постои еден-на-еден конкатенација помеѓу два ентитета, тоа значи дека клучниот идентификатор на една табела е присутен во другиот ентитет, тогаш една од табелите треба да се отстрани, таа е излишна. Но, понекогаш, поради безбедносни причини, програмерите намерно ги делат двата ентитета. Затоа, хипотетички може да постои еден-на-еден однос.

Постоењето на клучеви во релациона база на податоци

Примарните и секундарните клучеви го одредуваат потенцијалниот однос на базата на податоци. Моделите за релациони податоци може да имаат само еден потенцијален клуч, ова е примарен клуч. Што претставува тој? Примарниот клуч е ентитет колона или сет на атрибути, преку кои можете да пристапите до податоците од одреден ред. Мора да биде уникатен, уникатен и неговите полиња не можат да содржат празни вредности. Ако примарниот клуч се состои само од еден атрибут, тогаш се нарекува едноставен, инаку тоа ќе биде компонента.

Во прилог на примарниот клуч, исто така има и надворешен клуч. Многумина не ја разбираат разликата меѓу нив. Ајде да ги анализираме подетално со пример. Значи, постојат 2 маси: "Деканска канцеларија" и "Студенти". Суштината на "Deanery" содржи полиња: "Student ID", "Name" и "Group". Табелата "Студенти" има такви атрибутни вредности како "Име", "Група" и "Просечна оценка". Бидејќи студентот проект не може да биде ист за неколку студенти, ова поле ќе биде примарен клуч. "Име" и "Група" од табелата "Студенти" може да бидат исти за неколку лица, тие се однесуваат на бројот на студентот од ентитетот "Декан", за да можат да се користат како странски клуч.

Пример за модел на релациона база на податоци

За јасност, даваме едноставен пример за моделот на релациони бази на податоци кој се состои од два ентитета. Постои маса наречена "Деккан".

Суштината на "Deanery"

Студентски проект

Име

Групата

111

Иванов Олег Петрович

IN-41

222

Лазарев Илија Александрович

ВО-72

333

Конопле Петр Васильевич

IN-41

444

Кушнерева Наталија Игоревна

ВО-72

Треба да направите врски за да добиете целосна релациона база на податоци. Записот "IN-41", како и "IN-72", може да биде присутен повеќе пати во плочата на decanter, исто така, презимето, името и patronymic на учениците може да се совпаѓаат во ретки случаи, па затоа овие полиња не можат да бидат примарен клуч на кој било начин. Ајде да ја покажеме суштината на "Студентите".

Табела "Студенти"

Име

Групата

Просечна топка

Телефонски број

Иванов Олег Петрович

IN-41

3.0

2-27-36

Лазарев Илија Александрович

ВО-72

3.8

2-36-82

Конопле Петр Васильевич

IN-41

3.9

2-54-78

Кушнерева Наталија Игоревна

ВО-72

4.7

2-65-25

Како што можете да видите, полињата на релационата база на податоци се сосема различни. Постојат и дигитални и симболични записи. Затоа, во поставките за атрибутот, треба да ги специфицирате вредностите на цел број, знак, vachar, датум и други. Во табелата "Декан", само идентификацијата на ученикот е единствена вредност. Ова поле може да се земе како примарен клуч. Името, групата и телефонскиот број од субјектот "Студенти" може да се земат како странски клуч кој се однесува на идентификацијата на студентот. Комуникацијата е воспоставена. Ова е пример за еден-на-еден модел. Хипотетички една од табелите е излишна, лесно може да се комбинира во еден ентитет. За личните броеви на студенти не станаа универзално познати, тоа е сосема реално постоење на две маси.

Similar articles

 

 

 

 

Trending Now

 

 

 

 

Newest

Copyright © 2018 mk.unansea.com. Theme powered by WordPress.