За какво е първичният ключ на таблицата. Естествен и сурогатен ключ. Връзки много към много

• Превод

Публикувам продължението на превода на поредица от статии за начинаещи.
В настоящето и следващите - повече информация по същество.
Старт - .

4. ТАБЛИЦИ И ПЪРВИЧНИ КЛЮЧЕВИ

Както вече знаете от предишните глави, данните се съхраняват в маси, които съдържат струниили по друг начин записи... По-рано дадох пример за електронна таблица, съдържаща информация за урока. Нека го разгледаме отново.

В таблицата има 6 урока. Всичките 6 са различни, но за всеки урок стойностите на едни и същи полета се съхраняват в таблицата, а именно: tutorial_id (идентификатор на урока), заглавие (заглавие) и категория (категория). Tutorial_id – първичен ключтаблици за уроци. Първичният ключ е стойност, която е уникална за всеки запис в таблица.
В таблицата с клиенти по-долу, customer_id е първичният ключ. V в такъв случайпървичният ключ също е уникална стойност(номер) за всеки запис.

Първични ключовев ежедневието

В базата данни първичните ключове се използват за идентификация. В живота първичните ключове са навсякъде около нас. Всеки път, когато срещнете уникален номер, този номер може да служи като първичен ключ в базата данни (може, но не е задължително да се използва като такъв. Всички бази данни могат автоматично да генерират уникална стойност за всеки запис като число който автоматично се увеличава и вмъква заедно с всеки нов запис [Т. нар. синтетичен или сурогатен първичен ключ - прибл. превод]).

Няколко примера

• Номерът на поръчката, който получавате при покупка от онлайн магазин, може да бъде основният ключ на някаква таблица с поръчки в базата данни на този магазин, т.к. това е уникална стойност.
• номер социална осигуровкаможе да бъде първичен ключ в някаква таблица в базата данни държавна институцияот той също е уникален, както в предишния пример.
• Номерът на фактурата може да се използва като първичен ключ в таблицата на базата данни, която съхранява фактури, издадени на клиенти.
• Цифровият клиентски номер често се използва като първичен ключ в таблицата с клиенти.

Какво общо имат тези примери? Фактът, че във всички тях е избрана уникална, неповтаряща се стойност като първичен ключ за всеки запис. Отново. Стойностите на полето на таблицата на базата данни, избрано като първичен ключ, винаги са уникални.

Какво характеризира първичния ключ? Основни ключови характеристики.

Първичният ключ се използва за идентифициране на записи.

Първичният ключ се използва за идентификациязаписи в таблицата, така че всеки запис да стане уникален. Друга аналогия... Когато се обадите на сервиза техническа поддръжка, обикновено операторът ви моли да дадете номер (договор, телефон и т.н.), по който можете да бъдете идентифицирани в системата.
Ако сте забравили номера си, операторът за техническа поддръжка ще ви помоли да ви предоставите всякаква друга информация, която ще ви помогне уникално да ви идентифицира. Например комбинация от рожден ден и фамилия. Те могат да бъдат и първичен ключ, или по-скоро комбинация от тях.

Първичният ключ е уникален.

Първичният ключ винаги е уникален. Представете си, че значението му не е уникално. Тогава не може да се използва за идентифициране на данни в таблица. Това означава, че всяка стойност на първичен ключ може да се появи само веднъж в колона, която е избрана като първичен ключ. RDBMS са проектирани да ви предпазят от вмъкване на дубликати в полето на първичния ключ, ще получите грешка.
Още един пример. Представете си, че имате таблица с полета first_name и last_name и два записа:

| първо_име | фамилия |
| вася | тиква |
| вася | тиква |

Тези. има двама Васи. Искате да изберете конкретна Вася от таблицата. Как да го направим? Записите не се различават един от друг. Тук идва първичният ключ. Добавете колона с id (класически синтетичен първичен ключ) и ...

ID | първо_име | фамилия |
1 | вася | тиква |
2 | вася | тиква |

Сега всеки Вася е уникален.

Типове първични ключове.

Обикновено първичният ключ е числова стойност... Но може да бъде и всеки друг тип данни. Не е обичайна практика да се използва низ като първичен ключ (низът е част от текст), но теоретично и практически е възможно.
Съставни първични ключове.
Често първичният ключ се състои от едно поле, но може да бъде и комбинация от няколко колони, например две (три, четири ...). Но не забравяйте, че първичният ключ винаги е уникален, което означава, че комбинацията от n-тия брой полета, в този случай 2, трябва да бъде уникална. Ще ви разкажа повече за това по-късно.

Автоматично номериране.

Полето за първичен ключ често, но не винаги, се обработва от самата база данни. Можете, относително казано, да кажете на базата данни да присвоява автоматично уникална числова стойност на всеки запис, когато бъде създаден. Базата данни обикновено започва да номерира от 1 и увеличава този номер за всеки запис с един. Такъв първичен ключ се нарича автоматично нарастващ или автоматично номериран. Използване на клавиши за автоматично увеличение - добър начинза да зададете уникални първични ключове. Класическото име за такъв ключ е сурогатен първичен ключ [Както беше споменато по-горе. - прибл. превод]. Такъв ключ не съдържа полезна информация, свързан с обекта (обекта), информация за който се съхранява в таблицата, поради което се нарича сурогатна.

5. СВЪРЗВАНЕ НА ТАБЛИЦИ ИЗПОЛЗВАНЕ НА ВЪНШНИ КЛЮЧОВЕ

Когато започнах да разработвам бази данни, често се опитвах да съхранявам информация, която изглеждаше свързана в една таблица. Бих могъл, например, да съхранявам информация за поръчки в таблица с клиенти. Все пак поръчките принадлежат на клиенти, нали? Не. Клиентите и поръчките са отделни единици в базата данни. И двамата имат нужда от собствена маса. И записите в тези две таблици могат да бъдат свързани, за да се установи връзка между тях. Проектирането на база данни е за две неща:

• да определите какви обекти искате да съхранявате в него
• какви връзки съществуват между тези образувания

Едно към много.

Клиентите и поръчките имат връзка (са във връзка) едно към многозащото единклиентът може да има многопоръчки, но всяка конкретна поръчка (техн Много) издадени само единклиента, т.е. може да има само един клиент. Не се притеснявайте, ако е включен този моментразбирането за тази връзка е неясно. Ще говоря повече за връзките в следващите части.

Едно нещо е важно сега - че за комуникация един към много имате нужда двеотделни маси. Един за клиенти, един за поръчки. Нека потренираме малко, докато създаваме тези две таблици.

Каква информация ще съхраняваме? Решаваме първия въпрос.

Първо, ще определим за каква информация поръчкии около клиентище съхраняваме. За да направим това, трябва да си зададем въпроса: „Кои единични блокове информация се отнасят до клиентите и кои единични блокове информация се отнасят до поръчките?“

Проектираме маса с клиенти.

Поръчкинаистина принадлежат на клиенти, но поръчката не е минимален блок от информация, което се отнася до клиенти (т.е. този блок може да бъде разделен на по-малки: дата на поръчка, адрес за доставка на поръчка и т.н., например).
Полетата по-долу са минимални блоковеинформация, която се отнася до клиентите:

• customer_id (първичен ключ) - клиентски идентификатор
• първо_име - име
• фамилия - бащино име
• адрес - адрес
• пощенски код - пощенски код
• страна - държава
• рождена_дата - дата на раждане
• потребителско име - регистрационно имепотребителски вход)
• парола - парола

Нека да преминем към създаването на тази таблица директно в SQLyog (разбира се, можете да използвате всяка друга програма). По-долу е даден пример за това как може да изглежда таблицата в SQLyog, след като е била създадена. Всичко графични приложенияза управление на база данни имат приблизително същата структура на интерфейса. Можете също да създадете таблица с командна линиябез използване на графична помощна програма.

Създаване на таблица в SQLyog. Забележете, че квадратчето за отметка за първичен ключ (PK) е избрано за полето customer_id. Полето customer_id е първичният ключ. Също така е избрано квадратчето за отметка Auto Incr, което означава, че базата данни автоматично ще замени уникална цифрова стойност, която, започвайки от нула, ще се увеличава с една единица всеки път.

Изработваме таблица с поръчки.
Кои са минималните блокове информация, от които се нуждаем, свързани с поръчката?

• order_id (първичен ключ) - идентификатор на поръчката
• order_date - дата и час на поръчката
• клиент - клиентът, направил поръчката

По-долу е даден пример за таблица в SQLyog.

Тези две таблици ( клиентии поръчки) са свързани, защото полето клиентв таблицата с поръчки се отнася до първичния ключ ( Клиентски номер) клиентски маси. Тази връзка се нарича връзка с външен ключ... Трябва да мислите за външен ключ като обикновено копие(копие на стойност) на първичния ключ на друга таблица. В нашия случай стойността на полето Клиентски номерот масата клиентикопиран в таблицата поръчкипри вмъкване на всеки запис. Така всяка поръчка е обвързана с клиента. И всеки клиент може да има много поръчки, както беше споменато по-горе.

Създаване на връзка с външен ключ.

Може да се чудите: „Как мога да бъда сигурен или как мога да видя, че полето за клиент в таблицата с поръчките се отнася до полето customer_id в таблицата с клиенти“. Отговорът е прост - не можете да направите това, защото все още не съм ви показал как да създадете връзка.
По-долу е прозорец на SQLyog с прозорец, който използвах за създаване на връзка между таблици.

Създаване на връзка с външен ключ между таблиците на поръчките и клиентите.

В прозореца по-горе можете да видите как полето за клиенти на таблицата с поръчки отляво е свързано с първичния ключ (customer_id) на таблицата с клиенти отдясно.

Сега, когато погледнете данните, които биха могли да бъдат в таблиците, ще видите, че двете таблици са свързани.

Поръчките се свързват с клиенти чрез полето клиент, което се отнася до таблицата на клиентите.

На изображението можете да видите, че клиентът Дева Мариянаправи три поръчки, клиент паблопостави един и клиента Джон- никой.
Може да попитате: „А Каквовсички тези хора ли поръчаха?" то Добър въпрос... Може да сте очаквали да видите поръчаните артикули в таблицата за поръчки. Но това е лош пример за дизайн. Как бихте поставили няколко продукта в един запис? СтокиТова са отделни обекти, които трябва да се съхраняват в отделна таблица. И връзката между таблиците поръчкии стокище бъде връзка един към много. Ще говоря за това по-нататък.

6. СЪЗДАВАНЕ НА ДИАГРАМА СЪЩНОСТ-ВРЪЗКА

По-рано научихте как записи от различни таблици се свързват един с друг в релационни бази данни. Преди да създадете и свържете таблици, важно е да помислите субектикоито съществуват във вашата система (за която създавате база данни) и решете как биха били тези обекти се свързазаедно. При проектирането на база данни обектите и техните връзки обикновено се предоставят в диаграма субект-връзка (ERD). Тази диаграмае резултат от процеса на проектиране на база данни.

Субекти.

Може би се чудите какво точно е образувание. Е... това е „нещо“ в системата. Там. Майка ми винаги е искала да стана учител, защото съм много добър в обясняването на различни неща.

В контекста дизайн на база даннисъщността е нещо, което заслужававашата собствена таблица във вашия модел на база данни. Когато проектирате база данни, трябва да ги дефинирате субектив системата, за която създавате базата данни. По-скоро е въпрос на диалог с клиента или със себе си, за да разберете с какви данни ще работи вашата система.

Да вземем за пример онлайн магазин. Онлайн магазин продава стоки. Продуктможе да се превърне в очевиден обект в системата на онлайн магазин. Стоки поръчаклиенти... Тук сме с вас и видяхме още две очевидни образувания: поръчкии клиенти.

Поръчката се заплаща от клиента ... интересно е. Ще създадем ли отделна таблица за плащания в базата данни на нашия онлайн магазин? може би. Но наистина ли плащанията са най-малкият блок информация, свързан с поръчки? Това също е възможно.

Ако не сте сигурни, просто помислете какъв вид информация за плащане искате да съхранявате. Може да искате да съхранявате начин на плащанеили дата за плащане... Но това все още са минимални блокове информация, с които може да има връзка поръчка... Можете да промените формулировката. Начин на плащане - начинът на плащане за поръчката. Дата на плащане - датата на плащане на поръчката. Така че не виждам нужда да търпя плащанияв отделна таблица, въпреки че концептуално бихте могли да разграничите плащанията като субект, тъй като бихте могли да мислите за плащанията като за контейнер с информация (начин на плащане, дата на плащане).

Нека не бъдем твърде академични.

Както можете да видите, има разлика между обект и директно таблица в базата данни, т.е. те не са едно и също нещо. Професионалисти от индустрията информационни технологииможе да бъде МНОГО академичен и педантичен за това. Аз не съм такъв специалист. Тази разлика зависи от вашата гледна точка към вашите данни, вашата информация. Ако разглеждате моделирането на данни от гледна точка софтуер, тогава можете да се окажете с много обекти, които не могат да бъдат прехвърлени директно в базата данни. V това ръководствоние разглеждаме данните стриктно от гледна точка на базите данни и в нашата малък святедин обект е маса.

Изчакайте, наистина сте близо до получаването на вашата напреднала степен по бази данни.

Както можете да видите, определянето кои обекти има вашата система е малко интелектуален процес, който изисква известен опит и често е обект на промяна, ревизия, размисъл, но разбира се, това не е ракетна наука.

Диаграмата на същност-връзка може да бъде доста голяма, ако работите сложно приложение... Някои диаграми могат да съдържат стотици или дори хиляди таблици.

Връзки.

Втората стъпка в проектирането на база данни е да изберете какви връзки съществуват между обектите във вашата система. Сега това може да е малко трудно за разбиране, но, отново, това не е ракетна наука. С известен опит и преосмисляне на извършената работа, вие ще завършите следващия модел на базата данни по правилния или близо до правилния начин.

Така. Казах ти за връзката едно към многои ще ви разкажа повече за връзките в следващите части на този урок, така че засега няма да се спирам повече на това. Само не забравяйте, че решаването какви взаимоотношения ще имат вашите субекти е важна част. дизайн на база даннии тези връзки са показани на диаграмата същност-връзка.

таблици

В релационна база данни информацията е организирана в релационни таблици, разделени на редове и колони, в пресечната точка на които се съдържат стойностите на данните.

маса -това е някаква редовна структура, състояща се от краен набор от записи от същия тип.

Таблицата отразява типа на обекта (обекта) от реалния свят. Низовете съответстват на екземпляр на обект, конкретно събитие или явление. Колоните съответстват на атрибутите (характеристики, характеристики, параметри) на обект, събитие, явление. Всяка маса има уникално имевътре в базата данни, описвайки нейното съдържание.

Всяка колона в таблица има свое собствено име, което обикновено служи като заглавие на колоната. Всички колони в една и съща таблица трябва да имат уникални имена, но можете да присвоите едно и също име на колони, разположени в различни таблици. V релационен моделатрибутите на данни на релациите не са подредени, тоест полетата винаги са достъпни по име, а не по местоположение. Въпреки това, в SQL езикРазрешено е индексиране на колоните на таблицата, като колоните се разглеждат в ред отляво надясно (редът им се определя при създаването на таблицата).

Всяка таблица винаги има поне 1 колона. Стандартът ANSI / ISO не определя максимума допустимо числоколони в таблицата обаче, в почти всички търговски СУБД това ограничение съществува. В Firebird това ограничение е 32 767 колони.

В модела на данни RMDrelation концепцията за кортеж се използва за обозначаване на низ за връзка. Чрез представяне на кортеж в физическо нивое редът на таблицата на базата данни. Редовете в таблицата нямат имена и конкретен ред. Таблицата може да съдържа произволен брой редове. Напълно приемливо е да съществува таблица с нулеви редове. Такава маса се нарича празна. Празна таблица запазва структурата, дефинирана от нейните колони; тя просто не съдържа данни. По правило няма ограничения за броя на редовете в таблица, а в много СУБД размерът на таблиците е ограничен само от свободното пространство. дисково пространствокомпютър. Други СУБД имат максимална граница, обаче е доста висока - около два милиарда реда, а понякога и повече.

Нека илюстрираме по-ясно структурата на една от таблиците тренировъчна базаданни (вж. Приложение А). На фиг. 1.1 показва структурата на таблицата Abonent, която съдържа информация за абонатите на компаниите за жилищно-комунални услуги.

Ориз. 1.1.Структурата на релационната таблица на Abonent

Всяка хоризонтална линия в тази таблица представлява отделен физически субект - един абонат. Дванадесетте реда на таблицата заедно представляват всички абонати. Всички данни, съдържащи се в конкретен ред на таблицата, са набор от стойности на атрибути за конкретен абонат, който е описан от този ред.

Всяка вертикална колона в таблицата представлява колекция от стойности за конкретен атрибут на обект. Например колоната AccountCD съдържа уникални номера на лични акаунти на абонатите. Колоната Телефон съдържа телефонните номера на абонатите.

Има точно една стойност на данни в пресечната точка на всеки ред с всяка колона на таблицата. Например, в реда, представляващ абоната V. S. Konyukhov, колоната Fio съдържа стойността "V. S. Konyukhov". Колоната AccountCD на същия ред съдържа стойността "015527", която е номерът на личната сметка на абоната с пълното име на V.S.Konyukhov.

Всички стойности, съдържащи се в една и съща колона, са от един и същ тип данни. Например колоната Fio съдържа само думи, докато колоната StreetCD съдържа цели числа, представляващи идентификатори на улици. В релационен модел на данни, общият набор от стойности, от които да се вземат реални стойностиза определени атрибути (колони) се извиква домейн... Домейнът на колоната Fio, например, е набор от фамилни имена, имена и бащини (пълни имена) на абонатите. Всяка колона винаги е дефинирана в един и същ домейн.

В релационните бази данни домейн се дефинира чрез посочване на поне някакъв основен тип данни, към който принадлежат елементите на домейна, и често произволен. булев изразприлага се към елементи от този тип данни (ограничения на домейна).

Примерната база данни дефинира следните домейни:

§ Булев (логически): SMALLINT... Полетата, дефинирани в този домейн, могат да приемат само цели числа, равни на 0 или 1. Това се постига чрез налагане на условие за проверка (CHECK) в домейна на стойностите, приети от този домейн.

§ Пари: NUMERIC (15.2)... Домейнът е предназначен за дефиниране на полета в таблици, които съхраняват парични суми.

§ PKField: INTEGER... Домейнът е за дефиниране на първични и външни ключове на таблици. Няма ограничение за изискване за данни (NOT NULL) в този домейн. Той се наслагва, когато първичният ключ на таблицата е деклариран. Това се прави, за да можете да дефинирате външен ключ в този домейн без клаузата NOT NULL.

§ TМесец (Месец): SMALLINT... Домейнът е предназначен за дефиниране на полета, съдържащи номера на месеци в таблици. Целочислените стойности в такова поле могат да бъдат в диапазона 1 ... 12.

§ ГОДИНА: SMALLINT... Домейнът е предназначен за дефиниране на полета, съдържащи номера на годината. Целочислените стойности могат да бъдат в диапазона 1990 ... 2100.

Тъй като редовете в релационна таблица не са подредени, не можете да изберете ред по неговия номер в таблицата. В таблицата няма "първи", "последен" или "тринадесети" ред. Тогава как можете да посочите конкретен ред в таблицата, например ред за абонат с пълното име на SA Aksenov?

Ключов елементданнитакъв елемент се извиква, чрез който могат да се определят стойностите на други елементи от данни.

В релационна база данни всяка таблица има 1 или повече колони, чиито стойности са различни във всички редове. Тези колони(и) се наричат ​​първичен ключ на таблицата.

Първичен ключ -това е атрибут или група от атрибути, които уникално идентифицират всеки ред в таблица.

Нека се върнем към разглеждането на таблицата Abonent в примерната база данни (Фигура 1.1). На пръв поглед колоната AccountCD и колоната Fio могат да служат като първичен ключ на таблицата Abonent. Ако обаче са регистрирани 2 абоната с едно и също пълно име, тогава колоната Fio вече няма да може да играе ролята на първичен ключ. На практика идентификатори като напр уникален номерличен акаунт на абоната (AccountCD в таблицата Abonent), идентификатор на улицата (StreetCD в таблицата Street) и др.

Ако в таблицата няма полета, чиито стойности са уникални, за създаване на първичен ключ обикновено в нея се въвежда допълнително поле, стойностите на които СУБД може да разполага по свое усмотрение.

Ако първичният ключ е комбинация от колони, тогава такъв първичен ключ се извиква композитен.

Вторични ключовесе задават от полета, които често се използват при търсене или сортиране на данни. За разлика от първичните ключове, полетата за вторични ключове могат да съдържат неуникални стойности.

Дефинирани са три основни класа обекти:

1) Пръчка- независим субект. Заглавията са затворени в правоъгълник.

2) Асоциативен- връзка много към много между две или повече субекти. Асоциациите се считат за пълноправен субект. Те могат да участват в други асоциации и да имат набор от атрибути.

а. Обозначенията (означаващи обект) са връзки много към едно или едно към едно между две единици. Тя се различава от характеристиката по това, че не зависи от обозначаващия обект.

3) Характеристика(характеристика) - връзка под формата много към едно или едно към едно между две единици. Това е специален случай на асоциация. Единствената цел на характеристиката е да опише или изясни някакъв друг обект. Съществуването на характеристика зависи изцяло от обекта, който се характеризира.

Ключ или потенциален ключ е просто набор от атрибути, по чиито стойности можете уникално да намерите необходимия екземпляр на обект.

Минималността означава, че лексически от набор от който и да е атрибут не позволява идентифициране на обект от останалите.

Един от ключовете се приема като първичен ключ, а останалите се наричат ​​алтернативни ключове. Потенциално ключ, състоящ се от един атрибут, се нарича прост. Не е позволено първичният ключ на централен обект да приема не определено значение, в противен случай възниква противоречива ситуация - ще се появи неиндивидуализирана и следователно несъществуваща инстанция на ядрото. По същите причини е необходимо да се гарантира, че първичният ключ е уникален.

Ако обект C свързва обекти A и B, тогава той трябва да включва външни ключове, съответстващи на първичните ключове на обекти A и B.

За всеки външен ключ трябва да се решат три въпроса:

1) Може ли допълнителен външен ключ да приеме нулеви стойности (нулеви стойности), накратко, може ли да съществува някакъв екземпляр на обект, за който целевият обект, определен от външния ключ, е известен.

2) Какво трябва да се случи, когато се опитвате да изтриете целеви обект, който е препратен от външен ключ.

Има три възможни решения този въпрос:

Каскадни

Ограничение

Задаване на конкретна стойност

3) Какво трябва да се случи при опит за актуализиране на първичния ключ на целевия обект, посочен от някакъв външен ключ.

По този начин, за всеки външен ключ в дизайна на вашата база данни, трябва да специализирате не само полето или комбинацията от полета, които съставляват този външен ключ, но и отговорите на горните въпроси.

Типове данни и домейни.

Моделът на релационните данни се характеризира с проста структура от данни и удобно за потребителя представяне.

Релационният модел е предназначен да организира данни под формата на двуизмерни таблици. Релационната таблица е двуизмерен масиви има следните свойства:

1) Всеки елемент от таблицата е един елемент от данни

2) Всички колони в таблицата са хомогенни - всички елементи в колоната имат един и същ тип данни и дължина

3) Всяка колона има уникално име

4) В таблицата няма идентични редове

5) Редът на реда от колони може да бъде произволен

Типове данни

Всички данни, използвани в програмирането, имат свои собствени типове данни. Релационният модел изисква използваните типове данни да са прости.

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

1) Прости типове данни

2) Структурирани типоведанни

3) референтни типове данни

Простите (атомни) типове данни нямат вътрешна структура. Този тип данни се наричат ​​скаларни. Те включват булеви, числови, низови типове данни. Атомността е относително относително понятие. Така, тип низданните могат да се разглеждат като едномерен масивгерои и цял типданни като набор от битове. Единственото важно тук е, че при преминаване към такъв ниско нивосемантиката се губи, тоест смисълът на данните.

Структурирането на типове данни има за цел да дефинира сложни структури от данни, които са изградени от съставни елементи, които от своя страна могат да имат вътрешна структура (масиви, записи, структури).

Реферираният тип данни е предназначен да осигури възможността за насочване към други данни. Този тип данни е предназначен за процедурни езици, които имат области на паметта за съхранение на данни.

За модел на релационни данни типът на използваните данни не е толкова важен. Изискването типът данни да е прост трябва да се разбира по такъв начин, че релационните операции да не трябва да вземат предвид вътрешната структура на данните.

Домейн porno.ru

В релационния модел на данни концепцията за тип данни е тясно свързана с концепцията за домейн, което може да се разглежда като усъвършенстване на тип данни.

Домейн -семантична концепция. Може да се разглежда като подмножество от стойностите на някакъв тип данни.

Свойства на домейн:

1) домейнът има уникално име в базата данни

2) домейнът е дефиниран при някои прост типданни или в друг домейн

3) домейн може да има някакво логическо условие, което ви позволява да опишете подмножество от данни, разрешени за даден домейн.

4) домейнът носи известно семантично натоварване

Например, някакъв домейн D, което означава „възраст на служителя“, може да бъде описан като някакво подмножество от набора от естествени числа

D = (nϵN: n ≥ 18 и n ≤ 60)

Разликата между областта на понятието подмножество се състои именно във факта, че домейнът отразява семантиката на определено предметна област... Може да има няколко домейна, които съвпадат като подмножество, но носят различни значения. Например домейните „тегло на частта“ и „налично количество“ могат да бъдат описани по подобен начин като набор от неотрицателни цели числа, но значението на тези домейни ще бъде различно и те ще бъдат различни домейни. Основното значение на домейна е, че домейните ограничават сравненията. Не е правилно от логическа гледна точка да се сравняват стойностите на различни домейни, дори и да са от един и същи тип. Синтактично правилно е да се издаде списък на всички части, за които теглото на частта е по-голямо от наличното количество, не отговаря на значението на понятията количество и тегло.

5. Връзки и техните свойства, атрибути и кортежи.
Връзката е основна концепция в релационния модел на данни. Атрибут на връзката:<Имя_атрибута: Имя_домена>... Имената на атрибутите трябва да са уникални в рамките на връзката. Често имената на атрибутите са същите като съответните имена на домейни. Някаква релация R, дефинирана на множество от области D 1, D 2, ... D n, съдържа две части: заглавие и тяло. Заглавката на връзката съдържа фиксиран брой атрибути на връзката.

(,,…)

Тялото на връзката съдържа много картографии на връзката. Всяка карта на взаимоотношенията е набор от двойки от формата

<Имя_атрибута: Значение_атрибута>

(,,… ).

В този случай стойността Val i принадлежи на атрибута A i D i. стойността се записва:

R ( ,,…).

Броят на атрибутите в една връзка се нарича степен или арност на връзката. Броят на картите за взаимоотношения се нарича кардиналност на връзката. Заглавката на релацията описва декартовото произведение на домейните, върху които е дефинирана релацията. Заглавката е статична. Не се променя по време на работа с базата данни. Ако атрибутите се променят, добавят или премахват за връзка, резултатът е различна връзка. Тялото на релация е набор от картезии, тоест подмножество на декартовото произведение на домейни и е релация в математическия смисъл на думата. Тялото на връзката може да се промени по време на работа с базата данни, тоест картографията може да се променя, добавя и т.н.

Релационната база данни е набор от релации. Схемата на релационна база данни е набор от заглавки на релации, които са включени в база данни.

Въпреки че всяка връзка може да бъде представена като таблица, връзките не са таблица. Това са близки, но неподходящи понятия. Термините, използвани от релационния модел на данни, имат съответни "таблици" синоними.

Свойства на връзката

Свойствата на взаимоотношенията са главно разликите между връзките.

1) По отношение на неидентичните карти.

Тялото на връзката е набор от касети и като всеки комплект не може да съдържа неразличими елементи. Таблиците, за разлика от релациите, могат да съдържат едни и същи редове.

2) Картите не са подредени (отгоре надолу), тъй като тялото на релацията е множество.

Една и съща връзка не може да бъде изобразена различни масикъде отиват линиите различен ред

3) Атрибутите не са подредени отляво надясно. Тъй като всеки атрибут има уникално име в рамките на връзката, редът на атрибутите няма значение. Една и съща връзка може да бъде представена от различни таблици, в които колоните са в различен ред.

4) Всички стойности на атрибути са атомни.

От свойствата на връзката следва, че не всяка таблица може да дефинира връзки. За да направи това, тя трябва да има проста структура, не съдържат идентични линии, всяка от колоните му трябва да съдържа данни само от един тип и всички използвани типове данни трябва да са прости.

проблем логичен дизайн релационна базаданни се състои в вземане на информирано решение за това от какви отношения трябва да се състои базата данни и какви атрибути трябва да имат тези връзки.

Моделът на релационните данни обхваща две основни изискванияцелостта, която трябва да се поддържа във всяка система за управление на релационна база данни.

1) Изискването за целостта на обекта, което е, че всяко пренасяне на която и да е връзка трябва да бъде различимо от всяко друго пренасяне на тази връзка, тоест всяка връзка трябва да съдържа първичен ключ.

2) Изискването за целостта чрез препратка (изискване за целостта на външните ключове) е това за всяка стойност на външния ключ, по отношение на която референтната точка сочи,. Трябва да има martage със същата стойност на първичен ключ или стойността на външния ключ трябва да е недефинирана.

Това са електронни хранилища на информация, достъпът до които се осъществява с помощта на един или повече компютри. Обикновено базите данни се създават за съхраняване и достъп до данни, съдържащи информация за определена предметна област, тоест определена област от човешка дейност или част от реалния свят.

DBMS е софтуерза създаване, попълване, актуализиране и изтриване на база данни.

Единицата информация, съхранявана в базата данни, е таблица. Всяка таблица е колекция от редове и колони, където редовете съответстват на екземпляр на обект, конкретно събитие или явление, а колоните съответстват на атрибутите (характеристики, характеристики, параметри) на обект, събитие или явление. Всеки ред съдържа информация за конкретно събитие.

По отношение на база данни колоните на таблица се наричат ​​полета, а редовете й се наричат ​​записи.

Между отделните таблици на базата данни могат да съществуват връзки, тоест информацията от предишната таблица може да се добави към друга. БД, между отделните таблици на които има връзки, се наричат ​​релационни. Една и съща таблица може да бъде основна по отношение на една таблица на база данни и дъщерна по отношение на друга.

Таблици, свързани чрез връзки, взаимодействат на принципа главен-подчинен. Една и съща таблица може да бъде главна на една таблица на база данни и дъщерна на друга.

Предмет Това е нещо, което съществува и е различимо, с набор от свойства. Разликата между един обект и друг се определя от специфични стойности на свойствата.

Същността - отражение на обект в паметта на човек или компютър.

Атрибут - специфичната стойност на някое от свойствата на субекта.

Поле Това е единичен елемент в запис, който съхранява конкретна стойност за атрибут.

Комуникационно поле – това е полето, чрез което двете таблици са свързани.

Първични и вторични ключове

Всяка таблица на база данни може да има първичен ключ - това е поле или табор от полета, които уникално идентифицират запис.

Стойността на първичния ключ в таблицата на базата данни трябва да е уникална, тоест не трябва да има два или повече записа в таблицата със същата стойност на първичен ключ.

Първичните ключове улесняват установяването на връзки между таблиците. Тъй като първичният ключ трябва да е уникален, не могат да се използват всички полета на таблицата за него.

Ако в таблицата няма полета, чиито стойности са уникални, за създаване на първичен ключ обикновено се въвежда допълнително числово поле, чиито стойности СУБД може да разполага по свое усмотрение.

Вторичните ключове се задават от полета, които често се използват при търсене или сортиране на данни: индексите, изградени върху вторични ключове, ще помогнат на системата да намери желаните стойности, съхранени в съответните полета, много по-бързо.

За разлика от първичните ключове, полетата за вторични ключове може да не съдържат уникална информация.

Релационни връзки между таблици

Едно към едно. Връзка едно към едно възниква, когато един запис в родителската таблица съвпада с един запис в дъщерната таблица.

Тази връзка е много по-рядко срещана от връзката един към много; тя се използва, ако не искате таблицата на базата данни да набъбне от вторична таблица. Връзката едно към едно води до четимост свързана информацияв няколко таблици трябва да извършите няколко операции за четене, което забавя извличането на необходимата информация. Освен това бази данни, които включват таблици с връзка едно към едно, не могат да се считат за напълно нормализирани.

Подобно на връзката един към много, връзката един към един може да бъде твърда или нетвърда.

Първичният ключ е уникална характеристика за всеки запис в таблица. Access поддържа два типа първични ключове: прости и съставни.

В ролята прост ключедно от съществуващите полета на таблицата може да се появи, ако в това поле няма празни и повтарящи се стойности. Примери за такива полета могат да бъдат номера на превозни средства, инвентарни номера, идентификационни кодове. Съставният ключ се изгражда като комбинация от два или повече елемента от данни. За таблицата Служители, например, теоретично бихте могли да използвате комбинация от две полета, Фамилия и Име, като първичен ключ. Въпреки това е напълно възможно в компанията да се появи друг служител със същото име и фамилия като някой, който вече работи.

Очевидно са наложени доста строги изисквания към полето(та), което претендира да бъде първичен ключ. Поради това е общоприета практика да се създаде специално идентификационно поле, което действа като ключ (например клиентски код, код на поръчка). С добавянето на всеки нов входв таблицата се въвежда това поле специално значение(обикновено цифров), който уникално идентифицира записа. V Достъп до приложениетоМожете да организирате такова номериране благодарение на типа данни Counter, който присвоява собствен номер на всеки нов запис, генерирайки поредица от числа със стъпка 1 (или произволно).

Има основни правила, които се приемат за ключовете в Access:

За удобство ключовото поле обикновено се изписва първо в структурата на таблицата;

Ако за таблицата е дефиниран първичен ключ, Програма за достъпавтоматично блокира въвеждането на дублиращи се стойности в това поле, или Нулеви стойности(празен);

Access автоматично сортира записите в таблицата по техния първичен ключ;

Основното ключово поле е индекс, който прави сортирането и търсенето на записи по-бързо.

За да зададете първичния ключ за таблицата и да завършите създаването й в режим на проектиране, изпълнете следните стъпки:

В режим на проектиране изберете полето, което ще действа като първичен ключ;

Щракнете върху бутона Ключово поле в лентата с инструменти на Table Builder или изберете командата от главното меню Редактиране - Ключово поле (вляво ще се появи ключов символ до името на избраното поле);

След уточняване ключово полетаблицата трябва да бъде запазена, за което е необходимо да щракнете върху бутона Запиши в лентата с инструменти на дизайнера на таблица и в прозореца, който се отваря, въведете името на таблицата и натиснете бутона OK.

Ако не е дефиниран първичен ключ, се появява предупредително съобщение, когато излезете от режима на проектиране и Access ви подканва да създадете ключово поле, преди да затворите таблицата.

17. Видове връзки и тяхното изпълнение. Референтна цялост и нейното поддържане.

В релационна база данни връзките избягват излишъка на данни. Например, когато създадете база данни, съдържаща информация за книги, може да се окажете с таблица, наречена Книги, която съхранява параметрите на всяка книга, като нейното заглавие, дата на публикуване и издател. Освен това има и Допълнителна информацияиздателя, който може да искате да запазите, като телефонен номер, адрес и пощенски код. Ако ги съхранявате в таблица с книги, тогава телефонният номер на издателя ще се повтаря за всяка издадена от него книга.

По-правилен вариант е да поставите информация за издатели в отделна таблица "Издатели". В този случай таблицата „Книги“ ще съдържа връзки към записите на таблицата „Издатели“.

За да останете в синхрон, трябва да осигурите съгласуваност на данните между таблиците Books и Publishers. Връзките за целостта на данните ви позволяват да гарантирате, че данните в една таблица съвпадат с данните в друга. Например всяка книга в таблицата Книги е свързана с конкретен издател в таблицата Издатели. Не можете да добавите книга към таблицата за издател, който не е в базата данни.

Видове връзки между таблици

Комуникацията се осъществява чрез съпоставяне на данни в ключови колони; обикновено това са колони, които имат едно и също име и в двете таблици. В повечето случаи съвпадението е между първичния ключ на една таблица, който съдържа уникален идентификатор за всеки ред, и външния ключ на друга таблица. Например, можете да свържете продажбите на всяка публикация в продажба, като създадете колона publication_id в таблицата Books (първичен ключ) и колона publication_id в таблицата Sales (външен ключ).

Има три типа връзки между таблиците. Типът на връзката, която създавате, зависи от това как са дефинирани свързаните колони.

Връзки едно към много

Връзката един към много е най-често срещаният тип връзка. При такава връзка всеки ред от таблица A може да съответства на много редове от таблица B, но всеки ред от таблица B може да има само един ред от таблица A. Например, връзката един към много се установява между издателите и Таблици с книги: всяко от издателите може да публикува много книги, но всяка книга се издава само от едно издателство.

Връзката един към много се създава, когато само една от свързаните колони има уникално ограничение или е първичен ключ.

В Microsoft Access страната на връзката един към много, която съответства на първичен ключ, се обозначава със символ на ключ. Страната на връзката, на която отговаря външният ключ, се обозначава със символа за безкрайност.

Връзки много към много

При установяване на релация много към много, всеки ред от таблица A може да съответства на много редове от таблица B и обратно. Такава връзка се създава с помощта на трета таблица, наречена таблица за свързване, чийто първичен ключ се състои от външни ключове, свързани с таблици A и B. Например, връзката много към много се установява между „Автори“ и „Книги " таблици, дефинирани с помощта на връзки един към много изглед между всяка от тези таблици и таблицата Автори на книги. Първичният ключ на таблицата Автори на книги е комбинацията от Author_ID (първичния ключ на таблицата с авторите) и Book_ID (първичния ключ на таблицата със заглавия).

Връзки едно към едно

При установяване на връзка едно към едно, всеки ред от таблица А може да съответства само на един ред от таблица Б и обратно. Връзката едно към едно се създава, когато и двете свързани колони са първични ключове или имат уникални ограничения.

Този вид връзка се използва рядко, тъй като в такава ситуация свързаните данни обикновено могат да се съхраняват в една таблица. Можете да използвате връзка едно към едно в следните случаи.

За да разделите таблица, която има твърде много колони.

За да изолирате част от масата от съображения за сигурност.

За съхранение на данни за краткосрочна употреба, които най-лесно се изтриват чрез изчистване на таблицата.

За съхраняване на данни, отнасящи се само за подмножество от основната таблица.

В Microsoft Access страната на връзката едно към едно, която съответства на първичен ключ, се обозначава със символ на ключ. Страната на връзката, на която отговаря външният ключ, също се обозначава със символа на ключа.

Създаване на връзки между таблици

При свързване на таблици не е необходимо свързаните полета да имат едно и също име. Те обаче трябва да имат един и същ тип данни, освен ако полето на първичния ключ е от типа Counter. Можете да свържете поле за брояч с числово поле само ако свойството FieldSize на всяко е зададено на една и съща стойност. Например, можете да свържете колони Column и Numeric, ако свойството FieldSize на всяка е зададено на Long Integer. Дори ако и двете колони, които могат да се обвържат, са от тип "Numeric", стойността на свойството FieldSize за двете полета трябва да е една и съща.