Теоретични основи на организацията на БР. Модел на релационни данни.
(http://www.intuit.ru/departtent/database/rdbintro/)
Подходи към организацията на базите данни
Йерархични бази данни
Основата на този модел е йерархичен модел за данни. Този модел има един основен обект и останалите - подчинени - обекти, разположени на различни нива на йерархия. Връзките на обектите образуват йерархично дърво с един корен обект.
Йерархичната база данни се състои от поръчан набор от няколко случая на един вид дърво. Автоматично поддържа целостта на препратките между предците и потомството. Основното правило: никой потомък не може да съществува без ваша родител (вж. RERIS. 1).
Фиг. 1 диаграма на йерархичния модел на данни
Типичен представител (най-добре известен и общ) е компанията за управление на информацията (IMS) IBM. Първата версия се появява през 1968 г. Много бази данни на тази система все още се поддържат.
Мрежови бази данни
Мрежовият подход към организацията на данните е разширяване на йерархичната. При йерархични структури, потокът на потока трябва да има точно един прародител; В мрежовата структура на данните, потомък може да има произволен брой предци.
В модела на мрежовите данни всеки обект може да бъде основен и подчинен и може да участва в образуването на произволен брой отношения с други обекти. Базата данни на мрежата се състои от набор от записи и набор от връзки между тези записи и ако кажете по-точно - от набора от копия на всеки тип от набора на базата данни за запис на запис и набор от случаи на всеки тип от дадено набиране на типове комуникации (виж фиг. 2).
Фиг. 2 Схема на модела на мрежата
Типичен представител е интегрираната система за управление на бази данни (IDMS) на Cullinet Software, Inc., предназначена за използване на IBM Basic Class машини под контрола на повечето операционни системи. Архитектурата на системата се основава на програма за програмиране на база данни за данни (DBTG) на конференцията на езиците на системите за данни (CODASYL) - организация, отговорна за определянето на езика за програмиране на COBOL. Докладът на DBTG е публикуван през 1971 г., а по-късно се появяват няколко системи, включително IDMS.
Релационни бази данни
Смята се, че релационният подход към организацията на базата данни е положен в края на 60-те години. Edgarododd. През последните десетилетия този подход е най-често срещан (с резервация, която се нарича SQL базирана релационна база данни, в действителност, някои важни принципи на класическия релационен подход) са в подходящи. Предимствата на релационния подход за разглеждане на следните свойства: релационният подход се основава на малък брой интуитивни абстракции, въз основа на които е възможно просто моделиране на най-често срещаните обекти; Тези абстракции могат да бъдат точно и официално определени; Теоретичната основа на релационния подход към организацията на базите данни е прост и мощен математически апарат на теорията на комплектите и математическата логика; Релационният подход осигурява възможност за уникална манипулация на данни, без да е необходимо да се знае специфичната физическа организация на бази данни във външната памет. Компютърният свят незабавно не разпознава релационните системи. През 70-те години на миналия век, когато почти всички основни теоретични резултати вече бяха получени и дори съществували първите прототипи на релационните ДБМ, много авторитетни специалисти отказаха възможността да постигнат ефективното прилагане на такива системи. Въпреки това, предимствата на релационния подход и развитието на методите и алгоритмите на организацията и управлението на релационните бази данни доведоха до факта, че до края на 80-те години релационните системи бяха взети на световния пазар доминиращото положение на СУБД.
Моделът на релационните данни се основава на математически принципи, възникнали директно от теорията на комплектите и логиката на предикатите. Тези принципи първо се прилагат в областта на моделирането на данни в края на 60-те години. Д-р Е.Ф. Кодексът, който работи в IBM, и за първи път е публикуван в техническия статия "Модел на релационни данни за големи споделени банки данни". Тази статия е генерирането на текущата теория на релационната база данни. Д-р Код дефинира 13 Правила за релационния модел (които се наричат \u200b\u200b12 нормативни разпоредби).
12 Правила на CODDA:
1. Релационните СУБД трябва да могат напълно да контролират базата данни чрез своите относителни способности.
2. Информационно правило - цялата информация в релационната база данни (включително имена на таблици и колони) трябва да се определи строго като стойности в таблици.
3. Гарантиран достъп - всяка стойност в релационната база данни трябва да бъде гарантирана чрез комбинация от име на таблица, първични ключови стойности и име на колона
4. Поддръжка за празни стойности (нулева стойност) - DBMS трябва да може да работи с празни стойности (неизвестни или неизползвани стойности), за разлика от стойностите по подразбиране и независимо за всички домейни.
5. Онлайн релационна директория - описанието на базата данни и неговото съдържание трябва да бъдат представени на логическо ниво като таблица, до която исканията могат да се прилагат с помощта на езика на базата данни.
6. Всеобхватният език за управление на данни е най-малко един от поддържаните езици, трябва да има ясно определен синтаксис и да бъде изчерпателен. Тя трябва да подкрепя описанието на структурата на данните и да ги манипулира, правилата за почтеност, разрешение и транзакция.
7. Правило за актуализиране на представяне (изгледи) - Всички изявления, които се актуализират, могат да бъдат актуализирани чрез системата.
8. Вмъкване, актуализиране и изтриване - DBMS поддържа не само заявка за избор на данни, но и вмъкнете, актуализирате и премахнете
9. Независимост на физическите данни - по приложни програми и специални програми, тя логично не засяга промените във физически методи за достъп и структурите за съхранение на данни.
10. Данните логическа независимост - по програмните приложения и специалните програми логично не засягат, в разумни промени в структурите на структурата.
11. Независимост на целостта - базата данни следва да може да определи правилата за почтеност. Те трябва да бъдат поддържани онлайн и няма да има начин да се заобиколите около тях.
12. Независимост на разпространението - Приложните програми и специални програми не засягат логично, като данните за първи път се използват или използват повторно.
13. Недостатък - невъзможността за заобикаляне на правилата за целостта, определени чрез езика на базата данни, използвайки езици с ниско ниво
Кодексът предложи използването на релационна алгебра в SURBD, за да се прехвърлят данните в съответните комплекти. Той организира своята система за бази данни около концепцията, базирана на набори от данни.
Въведение в модел на релационни данни
Основните понятия на модела за релационни данни
Подчертаваме следните основни концепции за релационни бази данни: тип данни, домейн, атрибут, кортеж, съотношение, първичен ключ.
За да започнем, ще покажем смисъла на тези понятия за примера на връзката на служителите, съдържащи информация за служителите на някои предприятия (фиг. 3).
Фиг. 3 съотношението на основните понятия на релационния подход
Тип данни
Ценностите на данните, съхранявани в релационната база данни, са типифицирани, т.е. той е известен с вида на всяка съхранена стойност. Концепцията за типа данни в релационен модел на данни напълно отговаря на концепцията за типа данни в езиците за програмиране. Припомняме, че определянето на традиционния (неръд) се състои от три основни компонента: определяне на набора от стойности от този тип; определяне на набор от операции, приложими за типа стойности; Определяне на метода на външно представяне на типа стойности (литерали).
Обикновено в съвременните релационни бази данни позволяват съхранение на характер, цифрови данни (точни и приблизителни), специализирани цифрови данни (като "пари"), както и специални "времеви" данни (дата, време, интервал от време). Подход към прилагането на взаимоотношенията по отношение на потребителите на техните собствени типове данни се развива активно.
В примера на фиг. 3 Ние се занимаваме с три вида данни: струни от символи, цели числа и пари.
Домейн
Концепцията за домейн е по-специфична за бази данни, въпреки че има аналози с подтипове в някои програмни езици. Като цяло, домейнът се определя чрез определяне на определен основен вид данни, към които домейнните елементи и произволната логическа експресия, прилагани към елемента от този тип данни (домейн ограничения).
Елементът за данни е елемент от домейна в това и само ако изчисляването на този логически израз дава резултат от истината (за логически стойности, ние ще използваме последователно наименованията на истината и лъжа или вярно и невярно). Името, уникалното сред имената на всички области на базата данни, е свързано с всеки домейн.
Най-подходящото интуитивно тълкуване на концепцията за домейна е неговото възприятие като допустим потенциал, ограничено подмножество на стойностите от този тип. Например, имената на домейни в нашия пример са дефинирани на основния тип символни низове, но една от нейните стойности може да включва само тези линии, които могат да представляват имената (по-специално, за възможността за представяне на руски имена, такива линии не може да започне с мек или твърд знак и не може да бъде по-дълъг, например 20 знака). Ако някои атрибут на връзката се определят в определен домейн (като например на фиг. 3, а) атрибутът се определя на името на домейна), в бъдеще ограничаването на домейна играе ролята на ограничаване на наложената интетаност стойностите на този атрибут.
Трябва също да се отбележи и семантичната тежест на концепцията за домейна: данните се считат за сравними само когато се отнасят до един домейн. В нашия пример стойностите на домейна на номера на прохода и номерата на отделите се отнасят до вида цели числа, но не са сравними (би било безсмислено да се позволи да сравнят).
Заглавие Връзка, послание, Връзка на тялото, Ралитация, Променлива връзка
Концепцията за връзката е най-фундаментална в релационния подход към организацията на базите данни, тъй като N-Arny отношението е единствената обща структура на данните, съхранявани в релационната база данни. Това се отразява в цялостното име на подхода - срок релационни (релационни) получен от връзка. Самият термин обаче е изключително неточен, тъй като, който говори за всички запазени данни, трябва да имаме предвид вида на тези данни, стойностите на този тип и променливи, в които стойностите се запазват. Съответно, за изясняване на термина, връзката се разпределя за концепциите за връзката, стойностите на връзката и променливата връзка. Освен това ще се нуждаем от дъщерно понятие за конус.
Така, заглавие (или схема) Връзка R (HR) се нарича крайни много поръчани двойки тип
Ако всички атрибути на заглавия са дефинирани на различни области, след това да не произвеждат ненужни имена, разумно е да се използват имената на съответните области до именуване на атрибути (не забравяйте, разбира се, че това е само удобен метод за именуване, който не елиминира разликите между понятията на домейна и атрибута).
Tuple.tR, съответстващ на заглавието на човешките ресурси, наречен много поръчани тризнаци на формата
Значение VR Ratio R се нарича двойка HR и BR. Една от допустимите стойности на връзката на служителите е показана на фиг. 2.1.
В тази тема ще повдигна 6 нормални форми и методи за привеждане на таблици към тези форми.
Процесът на проектиране на базата данни с използването на метода NF е итеративен и се състои в последователен превод на съотношението 1NF в по-висок ред NF съгласно определени правила. Всеки следващ NF е ограничен от определен вид функционални зависимости и елиминиране на съответните аномалии при извършване на операции по отношение на отношенията между базата данни, както и запазването на свойствата на предишни НФ.
Използвани термини
Атрибут - собственост на някаква единица. Често се нарича поле за маса.Атрибута на домейна - много валидни стойности, които могат да приемат атрибут.
Съдебна зала - Крайният набор от взаимосвързани допустими стойности на атрибути, които заедно описват някаква същност (табличен низ).
Поведение - Крайният набор от кортежи (таблица).
Схема на връзките - окончателен набор от атрибути, които определят някаква същност. С други думи, това е структура на масата, състояща се от конкретен набор от полета.
Проекция - съотношението, получено от посочените заличаване и (или) пермутации на някои атрибути.
Функционална зависимост Между атрибутите (набори от атрибути) x и y означава, че за всяко допустимо набиране на кортежи в това отношение: ако две приказки съвпадат с стойността x, тогава те съвпадат със стойността на y. Например, ако стойността на името на компанията Дали Canonical Ltd, тогава "щабът" Атрибут на "щаба" в такъв кортем винаги ще бъде Милбанк Кула, Лондон, Великобритания. Означаване: (x) -\u003e (Y).
Нормална форма. - Изискване за структурата на таблиците в теорията на релационните бази данни за премахване на прекомерните функционални зависимости между атрибутите (полета за таблици) от базата данни.
Метод на нормални форми (NF) Тя се състои в събиране на информация за обектите за решаване на проблема в рамките на една връзка и последващото разлагане на това отношение в няколко взаимосвързани отношения въз основа на процедурите за нормализиране на отношенията.
Цел на нормализиране: Изключете излишното дублиране на данни, което причинява аномалии, които са възникнали при добавяне, редактиране и премахване на кортежи (редови на маса).
Аномалия Тази ситуация се нарича таблица на базата данни, която води до противоречие в базата данни или значително усложнява обработката на базата данни. Причината е прекомерното дублиране на данни в таблицата, което се нарича чрез наличие на функционални зависимости от не-ключови атрибути.
Модификации на аномалиите Той се проявява във факта, че променянето на някои данни може да доведе до гледане на цялата таблица и съответната промяна в някои таблични записи.
Делеция на аномалиите - Когато изтриете всяка корка от таблицата, информацията, която не е свързана с директен запис, може да бъде загубен.
Добавяне на аномалии Има, когато информацията в таблицата не може да бъде поставена, докато не бъде пълна, или вмъкването на записа се изисква допълнително гледане на таблицата.
Първа нормална форма.
Връзката е в 1NF, ако всичките му атрибути са прости, всички използвани домени трябва да съдържат само скаларни стойности. В таблицата не трябва да има повтарящи се повторения.Например, има таблица "автомобили":
Нарушаването на нормализацията 1NF се случва в моделите на BMW, защото Същата клетка съдържа списък с 3 елемента: m5, x5m, m1, т.е. Това не е атомно. Ние трансформираме таблицата до 1NF:
Втора нормална форма.
Съотношението е в 2NF, ако е в 1nF и всеки не е атрибутът на ключа, зависи от основния ключ (PC).Инистността означава, че съставът на потенциалния ключ няма по-малка подгрупа от атрибути, от които може да се изведе и тази функционална зависимост.
Например, таблицата е дадена:
Таблицата е в първата нормална форма, но не и във втория. Цената на автомобила зависи от модела и фирмата. Отстъпката зависи от компанията, т.е. зависимостта от първичния ключ е непълна. Това се коригира чрез разлагане на две взаимоотношения, в които ключовите атрибути зависят от компютъра.
Таблицата е в 2NF, но не и в 3 Нюф.
По отношение на атрибута "модел" е основният ключ. Няма лични телефони от колата, а телефонът зависи единствено от магазина.
По този начин, във връзка със следните функционални зависимости: модел → магазин, магазин → телефон, модел → телефон.
Модел на зависимост → Телефонът е преходен, следователно, съотношението не е в 3 ноември.
В резултат на отделянето на първоначалната връзка, две взаимоотношения се получават в 3 ноември:
Нормална форма на Boys Codd (NFBC) (лична форма на трета нормална форма)
Дефиницията на 3NF не е съвсем подходяща за следните взаимоотношения:1) Отношението има два или повече потенциални ключа;
2) два и повече потенциални ключове са композитни;
3) те се пресичат, т.е. Има поне един атрибут.
За отношения с един потенциален ключ (първичен), NFBC е 3 ноември.
Отношението е в NFBC, когато всеки нетривиален и невъзможен при лявата функционална зависимост има потенциален ключ като детерминант.
Да предположим, че се счита за отношение, което представлява данните за резервацията на деня на паркинга:
Тарифата има уникално име и зависи от избрания паркинг и наличност на обезщетения, по-специално:
- "Голям": паркинг 1 за бенефициенти
- "Стандарт": паркинг 1 за не бенефициенти
- "Premium-A": паркинг 2 за бенефициенти
- Premium-B: Паркинг 2 за не бенефициенти.
Отношението е в 3 ноември. Изискванията на втората нормална форма се изпълняват, тъй като всички атрибути са включени в някои от потенциалните ключове и няма неутрални атрибути. Има и транзитивни зависимости, които отговарят на изискванията на третата нормална форма. Въпреки това, има функционална тарифа за зависимост → паркинг, в който лявата част (детерминанта) не е потенциална ключова връзка, т.е. връзката не е в нормалната форма на момчетата - кода.
Недостатъкът на тази структура е, че например, по погрешка можете да придадете тарифата "наклоняване" за резервиране на втория паркинг, въпреки че може да се лекува само за първия паркинг.
Можете да подобрите структурата, като използвате разлагането на атрибута на два и да добавите атрибут. Има предимстваЧрез получаване на взаимоотношения, които отговарят на NFBC (атрибутите, включени в основния ключ, са подчертани.):
Тарифи
Резервация
Четвърта нормална форма.
Съотношението е в 4NF, ако се намира в NFBC и всички нетривиални много ценни зависимости са действително функционални зависимости в потенциалните му ключове.Във връзка с R (A, B, C) съществува многовисална зависимост. R.A -\u003e -\u003e R.B В това и само ако наборът от стойности В, съответстващ на двойката стойност А и С, зависи от и независимо от С.
Да предположим, че ресторантите произвеждат различни видове пица и ресторантьорски услуги само в определени райони на града. Композитният първичен ключ на съответната променлива връзка включва три атрибута: (ресторант, тип пица, зона за доставка).
Такова съотношение на променлива не съответства на 4NF, тъй като има следната многоценена зависимост:
(Ресторант) → (гледка към пица)
(Ресторант) → (зона за доставка)
Това, например, при добавянето на нов тип пица ще трябва да направи един нов контекст за всяка зона за доставка. Възможна е логическа аномалия, в която само някои области на доставка от ресторанта, обслужвани от ресторанта, ще съответстват на определен тип пица.
За да се предотврати аномалия, е необходимо да се разложи връзката, поставянето на независими факти в различни отношения. В този пример трябва да се направи разлагане (ресторант, вид пица) и (ресторант, доставяща зона).
Въпреки това, ако добавите атрибут, който функционално зависи от потенциалния ключ, например, цената, като се вземат предвид разходите за доставка (ресторант, вид пица, зона за доставка) → цена), тогава полученото отношение ще бъде в 4NF и Тя вече не подлежи на разлагане без загуба.
Пета нормална форма.
Връзките са в 5 nf, ако е в 4 ноември и няма сложни зависими връзки между атрибутите.Ако "атрибутът зависи от" Attribute_2 ", и на свой ред" Attribute_2 "зависи от" Attribute_3 "и" Attribute_3 "зависи от" Attribute_1 ", след това и трите атрибута са задължително включени в един кортед.
Това е много твърдо изискване, което може да се извърши само при допълнителни условия. На практика е трудно да се намери пример за прилагане на това изискване в чиста форма.
Например, някои таблици съдържа три "доставчик" атрибут, "продукт" и "купувач". Купувач1 придобива няколко стоки от доставчика1. Купувач 1 придоби нов продукт от доставчика2. Тогава, по силата на горепосоченото, доставчикът 1 е длъжен да предостави на купувача1 същия нов продукт, а доставчикът2 трябва да предостави на купувача 1, с изключение на новия продукт, цялата номенклатура на стоките на доставчика1. Това на практика не се случва. Купувачът е свободен в избора на стоки. Следователно, за да се елиминира отбелязаната трудност, и трите атрибута се разпределят в различни отношения (таблици). След разпределяне на три нови отношения (доставчик, продукт и купувач), е необходимо да се помни, че когато информацията извлича (например, купувачите и стоките), е необходимо да се комбинират всичките три връзки в искането. Всяка комбинация от свързването на два съотношения неизбежно ще доведе до извличане на неправилна (неправилна) информация. Някои DBM са оборудвани със специални механизми, които премахват ненадеждната информация. Въпреки това, трябва да следвате общата препоръка: структурата на структурата на базата данни трябва да бъде изградена по такъв начин, че да се избегне използването на 4NF и 5NF.
Петата нормална форма е насочена към работа с зависими съединения. Тези зависими връзки между трите атрибути са много редки. Зависимите връзки Четири, пет и повече атрибути, за да се определи почти невъзможно.
Ino-key нормална форма
Променливата връзка е в DCNF тогава и само ако всяко ограничение, наложено върху него, е логично следствие от ограниченията на домейни и ключови ограничения, наложени на тази променлива връзка.Ограничаването на домейна е ограничение, което трябва да се използва за специфична стойност на атрибута само от някои даден домейн. Ограничаването по своята същност е задачата на списъка (или логически еквивалент на списъка) на приемливите стойности на вида и съобщението, че посоченият атрибут има този тип.
Ключовото ограничение е ограничение, което твърди, че някои атрибути или комбинация от атрибути е потенциален ключ.
Всяка променлива връзка в DKNF е задължително в 5 nf. Въпреки това, не може да бъде доведена до dknf.
Шест нормална форма.
Променливата връзка е в шеста нормална форма, ако и само ако отговаря на всички нетрайни зависимости на съединението. От дефиницията следва, че променливата е в 6 NFF и само ако е невъзможна, т.е. не може да бъде подложена на по-нататъшно разлагане без загуба. Всяка променлива връзка, която се намира в 6 ноември, също се намира в 5 nf.Идеята за "разлагане до края" беше представена преди проучванията в областта на хронологичните данни, но не намери подкрепа. Въпреки това, за хронологични бази данни, максималното възможно разлагане ви позволява да се борите с резервията и опростява поддържането на целостта на базата данни.
За хронологични бази данни са дефинирани U_ оператори, които разопакова връзката в посочените атрибути, изпълнява съответната работа и опакова резултата. В този пример връзката на връзката трябва да бъде направена с помощта на оператора u_join.
Работници
Променливата връзка "Служителите" не е в 6 ноември и може да бъде подложена на разлагане на променливите на "длъжностите на работниците" и "домашни адреси на работниците".
Длъжности на работници
Начало адреси на работниците
Литература
За по-дълбоко и задълбочено проучване на разглежданата тема, книгата "Въведение в системата на базата данни" на Крис Дж. Данни, въз основа на посочените материали на този член.Списък на въпросите за дисциплината "Бази данни и мрежови бази данни"
Концепцията и принципите на изграждане на бази данни.
BD -това е комбинация от свързани данни, организирани от определени правила.
Принципи на изграждане на бази данни
За съвременните бази данни и следователно, СУБД, на които са построени, са представени следните основни изисквания.
1. Висока скорост (малко време за реакция при поискване).
2. Лесен за актуализиране на данните.
3. Независимост на данните.
4. Споделяне на данни от много потребители.
5. Сигурност на данните - защита на данните от умишлено или неволно нарушение на секретността, изкривяването или унищожаването.
6. Стандартизация на изграждането и експлоатацията на базата данни (всъщност DBMS).
8. Приятелски потребителски интерфейс.
Релационен модел. Три аспекта на модела. Основни понятия, които са в основата на релационния модел.
Модел на релационни данни Това е удобната и най-позната форма на представяне на данни под формата на таблица.
За разлика от йерархичните и мрежовите модели, този метод на представяне: 1) е разбираем за потребителя без програмист; 2) улеснява променянето на схемата - прикрепете нови елементи и записи, без да променяте съответния пластир; 3) осигурява необходимата гъвкавост при извършване на непредвидени искания.
Едно от основните предимства на релационния модел е нейната хомогенност.
Основните понятия, с които се определят релационният модел, са следните: домейн, отношение, кортеж, кардинал, атрибути, степен, първичен ключ.
Домейнът е набор от стойности, от които се вземат стойностите на съответните атрибути на определена връзка. От гледна точка на програмирането, домейнът е тип данни, определен от системата (стандартна) или потребител.
Tuple - маса.
Кардалност - броят на редовете в таблицата.
Атрибут - поле, колона с таблица.
Степента на връзката е броят на полетата, колони.
Първичният ключ е колона или някаква подгрупа от колони, които са уникални, т.е. Единични дефиниращи струни.
Външният клавиш е колона или подгрупа от една таблица, която може да служи като първичен ключ за друга таблица.
Моделът поставя следните изисквания за таблици:
1. Таблиците в клетките трябва да бъдат структурно неделими;
2. В една колона трябва да бъде един тип;
3. Всяка колона трябва да бъде уникална (неприемливо дублиране на колони);
4. племената са поставени в произволен ред;
5. стандартите са поставени в таблицата и в произволен ред;
6. Племените имат уникални имена.
Отношения. Обща променливи. Значението на отношенията, собственост. Домейни.
Домейнът е най-малката семантична единица данни, която се приема, че е отделна стойност на данните (като студентски номер, име на ученик и др.). Такива стойности се наричат \u200b\u200bскалари. Скаларните стойности са най-малката семантична единица данни в смисъл, че са атомни: в релационния модел те нямат вътрешна структура. Трябва да се отбележи, че липсата на вътрешна структура по време на разглеждане в релационния модел не означава, че вътрешната структура изобщо липсва. Например, името на града има вътрешна структура (тя се състои от поредица от писма) обаче, разграждането на името според буквите ще загубим стойност. Стойността ще стане разбираема само ако буквите са сгънати заедно и в правилната последователност.
домейн - наречена много скаларни стойности от същия тип.
Основната стойност на домейните е, че домейните ограничават сравненията. Сравнението ще има смисъл за атрибути въз основа на същия домейн.
Отношения. Свойства и видове взаимоотношения
Имаше някаква неяснота в концепцията за "отношение" поради липсата на ясно разграничение между променливите и ценностите на връзката. Променливата връзка е обичайната променлива, същата като в програмните езици, т.е. Наречен обект, чиято стойност може да варира с времето. И стойността на тази променлива по всяко време ще бъде стойността на връзката.
Свойства на взаимоотношенията
1. Няма идентични корти.
2. Кортите не се поръчват отгоре надолу.
3. Атрибутите не са поръчани вляво отдясно.
4. Всички стойности на атрибути.
Видове взаимоотношения
1. Наречено отношение е променлива връзка, определена в СУБД чрез отношения за създаване на отношения.
2. Основното съотношение се нарича име, което не е получено (т.е., основната връзка е автономна).
3. Производството на съотношението е определено съотношение (чрез релационен израз) чрез други посочени изрази и в крайна сметка чрез основните взаимоотношения.
4. Изразеното отношение е съотношение, което може да бъде получено от набор от отношения чрез някои релационни израз. Много от всички изразени взаимоотношения са точно набор от всички основни отношения и всички деривативни отношения.
5. Представянето е посочено производно. Представителствата, както и основните отношения са променливи взаимоотношения. Представителни са виртуални - те са представени в системата изключително чрез определението по отношение на други имена.
6-годишните се наричат \u200b\u200bдеривати, за разлика от представянето са реални и представени в системата не само под формата на определения по отношение на други посочени отношения, но и от техните данни.
7. Резултатът от заявката се нарича неназовано съотношение на деривати, което служи в резултат на определена заявка.
8. Междинният резултат се нарича неназовано съотношение на деривати, което е резултат от някакъв релационен израз, вграден в друг, по-голям израз.
9. Съхранено отношение - отношението, което се поддържа директно във физическата памет.
Ключовете на променливи взаимоотношения. Видове ключове.
Потенциални ключове
Нека R е променливо отношение. По дефиниция наборът от атрибути на съотношението на променливото съотношение R има свойство на уникалност, т.е. По всяко време не два клона се дублират помежду си. На практика, определена подгрупа от набора от всички атрибути на съотношението променливо съотношение R също има свойство на уникалност.
Нека k е набор от атрибути на r) променливите атрибути. В този случай, зададеният k ще бъде потенциалният ключ на променливото съотношение R, тогава и само когато има следните свойства:
а) уникалност. Не допустими стойности на отношението на променливото съотношение R не съдържат две различни кортежи със същите стойности на атрибута на зададената К.
б) Недостатък. Нито един от собствените си подгрупи на комплекта К не притежава собственост на уникалност.
Привличаме внимание на факта, че всяко променливо отношение има поне един потенциален ключ. Важно е да се наблюдава спазването на свойствата на недостатъка, тъй като в случай, че потенциалният ключ е направен от известно предположение за множество атрибути с имуществото на уникалността, системата в този случай ще поддържа по-слаба ограничение на целостта и, като Резултатът ще бъде възможно съхранение в цената, свързана с промените със същата стойност на атрибута, която всъщност притежава собственост на уникалност. Поради тази причина потенциалните ключове не съдържат никакви атрибути, които не са свързани с гарантиране на нейната уникална идентификация.
Възможно е, когато променливото отношение има композитен ключ, т.е. Потенциален ключ, съдържащ повече от един атрибут. Потенциалният ключ, състоящ се от един атрибут, се нарича прост. Една променлива връзка може да има няколко потенциални ключа, а някои от тях могат да бъдат прости, други композитни.
Superkey се нарича някакъв потенциален ключов предложение. Супер сън има собственост на уникалност, но не разполага с неблагоприятно положение.
12. Възможности за данни. Отношения. Съотношение на променливо съотношение. Синтаксиса на оператора за създаване и премахване на основната връзка. Структура и свойства на собствеността. Видове взаимоотношения.
Основните концепции за релационни бази данни са типа данни, домейн, атрибут, кортеж, първичен ключ и отношение.
Типове данни: Като правило типовете данни са разделени на три групи: 1) прости типове данни. 2) структурирани типове данни. (Масиви, структури). 3) Типове данни. (указатели).
Релационният модел изисква видовете данни, използвани за прости (не притежавани вътрешна структура).
Домейни са типове данни, които имат известен смисъл (семантика). Домейнът се характеризира със следните свойства:
Домейнът има уникално име (в рамките на базата данни).
Домейнът се дефинира на някакъв прост тип данни или в друг домейн.
Домейнът може да има някакво логическо състояние, което ви позволява да опишете подмножество от данни, разрешени за този домейн.
Домейнът носи определен семантичен товар.
TUPLE, Отношение
Tuple е набор от посочени стойности на определен тип. Съотношението е набор от кортежи, съответстващи на една схема на връзката.
Обичайното ежедневно представяне на връзката е таблицата, чието заглавие е схемата на връзката и линиите - кората на образеца; В този случай имената на атрибутите се отнасят до колоните на тази таблица.
Свойства на отношенията: 1) Няма идентични кортежи по отношение на това. 2) Коргерите не са поръчани (отгоре надолу). 3) Атрибутите не са поръчани (от ляво на дясно). 4) Всички стойности на атрибутите са атомни.
Релационната база данни се нарича набор от взаимоотношения. Релационната верига на базата данни се нарича набор от заглавия за връзка, включени в базата данни.
Сега се обърнете към променливата във връзка (променлива на връзката или съкратено ReLvar). Както е отбелязано в глава 3, променливите взаимоотношения имат две разновидности - основни взаимоотношения и подаване на основни променливи (наричани и съответно реални и виртуални променливи на връзката). В този раздел ние се интересуваме основно от основните променливи взаимоотношения (презентациите са подробно обсъдени в глава 10), но трябва да се отбележи, че всички отношения са приложени тук без допълнително усъвършенстване за всички променливи като цяло, \\ t включително подавания.
Определяне на основната връзка
Синтаксисът на дефиницията на основната променлива е показан по-долу.
Var.
Параметър тип връзка
Връзка (
Ето параметъра
VAR S базовата връзка
Име, статус
Цяло число, градски char
) Първичен ключ (S #
VAR P основна връзка (R # R #, име на PNAME,
Цвят на цвета, тегло на теглото, град Char)
Първичен ключ (P #);
Var sp база връзка (s # s #, p # p #, qty comty)
Първичен ключ (S #, P #) Чуждестранен ключ (S #)
Референции S Чуждестранен ключ (P #
) Препратки p;;
Обяснения
1. Тези три основни променливи имат следните видове (взаимоотношения).
Връзка (s # s #, примамка име, статус цяло число, city char) връзка (p # p #, име на pname, цвят цвят,
Тегло, град
Char) връзка (s # s #, p # p #, qty comty)
2. Всички условия заглавие, тяло, атрибут, кортеж, степен (и т.н.), които преди това са били дефинирани за стойности на връзката, също така очевидно по отношение на променливата връзка.
3. Всички възможни стойности на всяка една променлива връзка принадлежат към един и същ вид връзка, а именно връзката, посочена в определението за променлива връзка (определено непряко, ако тази променлива връзка е презентация) и следователно имат същото заглавие.
4. При определяне на основната променлива връзката се присвоява първоначален знак което е празно отношение на съответния тип.
5. Определенията на потенциалните ключове са подробно обсъдени в глава 9 и в момента просто ще приемем, че определението за всяка основна променлива връзка включва една и само една дефиниция на потенциален ключ, \\ t<ключ за кандидат DEF\u003e в следващата конкретна форма.
Първичен ключ (
6. Определенията на външния ключ също се обсъждат в глава 9.
7. Въвеждане на определението за нова променлива връзка принуждава системата да влезе в директорията на запис с описанието на тази променлива връзка.
8. Както е отбелязано в глава 3, променливи взаимоотношения, както и отношенията, имат подходящо предикат. Такова е предиката обща за всички отношения, които представляват възможните стойности на разглежданите прехвърлени отношения. Например, в случай на променливо съотношение на връзката, предиката изглежда приблизително, както следва.
Доставчик с номер на доставчик на доставчици работи по договора, има името на името и състоянието на състоянието и се намира в град
9. Предполага се, че средствата се предоставят стойности по подразбиранеза атрибути на основни променливи взаимоотношения. Стойности по подразбиране посоченият атрибут е такава стойност, която трябва да бъде поставена в положението на съответния атрибут, ако потребителят ясно не осигурява желаната стойност при вмъкване на някаква кора. Подходящият синтаксис дизайн на урока D език за определяне на стойностите по подразбиране може да бъде под формата на нов дизайн в дефиницията на основната променлива, да речем, по подразбиране
Синтаксиса на оператора за създаване и премахване на основната връзка
Създайте виж торер като
) (EMP #, понастоящем, заплата);
(EMP, където заплата\u003e 3 3k
Забележка. Тъй като в момента е незначителен, в примера за удобство, смесена нотация на SQL езиците и ръководството D. се използва.
При извършване на този оператор, изразът, следващ ключовата дума като и
всъщност дефиниранене се изчислява, но просто запомнени системата (обикновено чрез записване в директорията под определеното име на torreere). Въпреки това, от гледна точка на потребителя, всичко изглежда така, сякаш се появява в базата данни
реална променлива връзка с името Torrere, която има текущата стойност, която е показана на фиг. 3.7 само в неизброими зони. И потребителят трябва да може да работи с този поглед точно така, сякаш това е конвенционална променлива връзка на базата данни.
Като друг пример, помислете за операцията за изтриване на изтриване.
Изтрийте Topemp, където заплатата< 42K ;
Всъщност ще се извърши следната операция.
Изтрийте EMP, където заплатата\u003e zzk и заплата< 42К;
Изследваният тук тест е много прост, състоящ се (експресиране на неформално) от подгрупа от редове и колони с една базова променлива връзка. По принцип обаче определението за представяне може да има произволна сложност (Може дори да се позове на други мнения). Например, освен това представлява определението, което включва връзката на две основни променливи.
Създайте виж Джонекс като
((EMP се присъедини към DEPT), където бюджетът\u003e 7м) (EMP #, dept #);
По въпроса за определянето и преработката на представителствата ще се върнем към глава 10. Между другото, сега е възможно да се обясни смисъла на забележките, дадени в края на раздел 2.2 по отношение на термина представителство(Преглед) в релационен контекст има доста специфична стойност, която не съвпада със стойността, която се приписва в архитектурата ANSI / SPARC. На външното ниво на тази архитектура базата данни се възприема като външно представителствоопределената външна схема (и различни потребители могат да имат различни външни изявления). В релационните системи, напротив, гледната точка, както е обяснено по-горе, е специално наречена деривативна виртуална променлива връзка. Следователно, релационен аналог външно представителство ANSI / SPARC обикновено служи много от няколко променливи взаимоотношения, всяка от които е презентация в отношенията. Външна схема се състои в идентифициране на такива изявления. (От това следва, че релационният модел е един от начините да се гарантира логическа независимост от данните,въпреки че трябва да се отбележи, че съвременните търговски продукти имат сериозни недостатъци в тази част. Подробности са дадени в глава 10.)
Видове взаимоотношения
И накрая, ние даваме дефиницията на отношението, като определен връх на пирамидата, състояща се от всички предишни концепции. Така, поведение (обозначава r.от английски Връзка - "съотношение") със схемата на отношенията S се определя като непременно крайна набор от кортежи, имащи същата схема на S.
r ≡ r (s) \u003d (t (s) | t∈ r);
По аналогия с схеми за връзка, броят на корпусите се нарича способността на взаимоотношенията и означават като силата на комплекта: | r.|.
Взаимоотношенията, като кортите, се различават по вид. Така връзката се нарича:
1) по-специалноАко следното условие е изпълнено за всяка входяща цена :.
Това (както при кортите) общия случай;
2) пълен, в случай че ∀ t ∈ R (S) се извършва :;
3) непълнаако ∃t ∈ r (s) def (t) ⊂ s;
4) никъде не са дефинираниако ∀t ∈ R (s).
Ще обърнем внимание на навсякъде, които не са дефинирани взаимоотношения. За разлика от кортежите, работата с такива взаимоотношения включва малка финес. Факт е, че никъде другаде може да има два вида: те могат да бъдат или празни, или могат да съдържат един никъде без определен кортеж (такива връзки са обозначени (∅ (и))).
Сравнима (по аналогия с приказките), т.е., евентуално равен, само връзките са със същата схема на връзката. Ето защо отношенията с различни схеми на взаимоотношения са различни.
В табличната форма връзката е тялото на таблицата, към която съответства низът - заглавката на колоните, т.е. буквално - цялата таблица, заедно с първия низ, съдържащ заглавия.
114 Част I. Основни понятия
3.5. ОПТИМИЗАЦИЯ
Както е описано в раздел 3.2, всички релационни операции, като съкращение, проекция и съединение, се изпълняват mstty ниво.Ето защо, релационните езици често се наричат \u200b\u200bфабриката, тъй като потребителят показва какво да прави, но да се прави Некак. Всъщност, потребителят съобщава само, че той се нуждае, без да уточнява процедурата за резултати. Обработка (движение) Според съхранената база данни, за да удовлетворите искането на потребителя, системата автоматично се изпълнява, а не от потребителя ръчно. Следователно, релационните системи понякога се наричат \u200b\u200bсистеми автоматична навигация.В нереалните системи самият потребител е основно отговорен за навигацията на базата данни. На фиг. 3.5 показва ярка илюстрация на предимствата на автоматичното навигация - SQL Inserger Language Operation се противопоставя на навигационния код, приготвен от "Ръчно". За да се получи същия резултат, този код е вероятно да бъде изготвен от потребител на всяка система, която не е свързана (в този случай, системата за кодасил мрежова система; пример се взема от главата в мрежовите бази данни б). Трябва да се отбележи, че тук базата данни за детайлите и доставчиците се използват като пример. За подробности вижте раздел 3.9.
Въпреки предишните коментари, трябва да се отбележи, че незабелязаното е, макар и общоприето, но не точно точен термин, защото има фактионна инвестиция - концепциите са относителни. Обикновено е възможно да се определи с увереност, само ако има език и повече (или по-малко) процедура, отколкото езика Б. следователно ще се каже, че се характеризират релационните езици като SQL като SQL по-високо ниво на абстракция,от типични езици за програмиране като C ++ или COBOL (или DATA SUBLICAS, които обикновено принадлежат към нерегулираните СУБД; виж фиг. 3.5). По принцип, това е по-високо ниво на абстракция, което спомага за увеличаването на производителността на програмистите, присъщи на релационните системи.
Отговорността за организиране на изпълнението на автоматична навигация се присвоява на много важен компонент на СУБД - оптимизатор (вече го споменахме в глава 2). С други думи, оптимизаторната работа е да изберете най-ефективния начин за изпълнение за всяко искане на потребителя. Да предположим, например, че потребителят е направил следното искане (ще използваме езика на урока D).
(EMP, където EMP # \u003d EMP # ("E4")) (Заплата)
Обяснение. Изразът в първите скоби (EMP където ...) означава, че работата на намаляването на текущата стойност на съотношението на ЕПС на съотношението, свързано с реда, в който се прилага стойността на колоната EMRE E4. Използваният тук езиков дизайн, който е името на колоната, сключен в къдрави скоби, което означава резултат от операцията по колоната на заплатата. Резултатът от тази прожекционна операция става връзка, състояща се от една колона и един ред, който съдържа данни за получаването на служител на E4. (Моля, обърнете внимание, че в този случай, релационните свойства се използват в имплицитна форма: написахме инвестиран израз, в който резултатът от операцията за намаляване се използва като входни данни за прожекционната операция.)
Фиг. 3.5. Примеси за навигация
Daezhetomosprostom-привидно целесъобразност на необходимите данни.
1. Последователно физическо преглеждане (съхранена версия) на съотношението на променливата на EMP, докато се намери желаният запис.
2. Ако има индекс за колонаEMP # (в съхранената версия) на променливо съотношение (което вероятно съществува, тъй като тази колона е уникална и повечето от системите действително ще създадат индекс, за да осигурят уникалност), след това преходът, използващ този индекс, е директно към тази услуга с E4 номера.
Оптимизаторът ще определи коя от двете възможни стратегии трябва да се прилагат. Като цяло, за прилагане на конкретно релакулно искане, оптимизаторът ще направи избор на стратегия, основана на съображения, както следва:
116 Част I. Основни понятия
■ какви променливи отношения са връзки в заявката;
■ колко големи са тези променливи взаимоотношения;
■ какви са индексите;
■ как са гласуването тези индекси;
■ как физически групирани данни на диска;
■ какви се използват релационни операции; и т.н.
Ето защо повтаряме: Потребителят показва заявка, която е необходима, и е необходимо да ги получавате, докато стратегията за достъп до данни е избрана от оптимизатора (автоматична навигация). В резултат на това потребителите и потребителските програми стават независими от използваните стратегии за достъп, които, разбира се, е абсолютно необходимо, ако искаме да постигнем реална независимост от физическото представяне на данните.
Повече информация за оптимизатора е дадена в глава 18.
3.6. Каталог
Както е отбелязано в глава 2, всеки СУБД трябва да подкрепя функциите на каталога или словар. Каталогът обикновено се поставя там, където се съхраняват различни схеми (външни, концептуални, вътрешни) и всичко, което се отнася до картите ("външна защита", "концептуално-вътрешно", "външно външно"). С други думи, каталогът съдържа подробна информация (понякога се нарича описателна информацияили метаданни) относно различни обекти, които имат значение за самата система. Примери за такива обекти могат да служат като променливи, индекси, ограничения върху подкрепата за целостта, ограниченията за защита и др. Необходима е описателна информация, за да се гарантира правилното функциониране на системата. Например, оптимизаторът използва информация за директорията за индекси и други физически хранителни структури, както и друга информация, необходима за вземане на решение как да извърши конкретна заявка за потребителя (вж. Глава 18). По същия начин, подсистемата за сигурност използва информация за директорията за потребителите и инсталираните ограничения за защита (глава 17), за да позволи или деактивира изпълнението на полученото искане.
Чудесната собственост на релационните системи е, че техните каталогът се състои и от променливи взаимоотношения.(по-точно, случайни променливи,
звучеше така, за да ги различи от обикновен потребител). В резултат на това потребителят може да има достъп до каталога по същия начин като данните си. Например, в каталога на всяка SQL система, променливите на системните таблици и колони обикновено се съдържат, чиято цел е описание на известната система за таблици (т.е. променливи) и колони на тези таблици. За база данни на отдели и служители, таблиците и колоните на променливите съотношения4 могат да бъдат схематично представени като йерархична структура, както е показано на фиг. 3.6.
4 Обърнете внимание, че базирана на RowCount колона в тази цифра можете да направите следното за шоуто: Изпълнението в базата данни на вмъкване и изтриване на операции като страничен ефект от данните за каталога ще се актуализира. На практика колоната RowCount обикновено се актуализира само на специална заявка (например, когато стартирате някаква полезност), така че стойностите на тази колона няма да бъдат подходящи.
Фиг. 3.6. Директория на базата данни на отделите и служителите (показани схематично)
Забележка. Както е посочено в глава 2, каталогът също трябва да се опише, т.е. Активиране на записи, които описват променливото съотношение на директорията (виж ex. 3.3).
Сега да предположим, че потребителската база данни и служителите трябва да разберат точно кои колони съдържат променлива отделска връзка (разбира се, предполага се, че по някаква причина потребителят няма тази информация). Тогава необходимия израз ще изглежда така.
(Колони, където табуто \u003d "dept") (colname)
Ето още един пример. Нека е необходимо да се знае, че променливата връзка е колона #.
(Колони, където colname \u003d "EMP #") (TABNAME)
Упражнения.Какво ще бъде резултат от следния израз?
((Таблици се присъединяват към колони)
Където colcount.< 5) { TABNAME, COLNAME }
3.7. Основни взаимоотношения и изгледи на променливи
Вече видяхме, че въз основа на релационни ценности, присвоени на определен набор от променливи отношения, подобни на Dept и EMM, релационните изрази позволяват да се получат много други стойности на връзката, например, в резултат на свързването на две променливи. Сега трябва да въведете още нови термини. Източник (зададени) променливи на връзката се наричат основни взаимоотношения на променливии значенията им се наричат \u200b\u200bосновни отношения. Връзката, която се получава или може да бъде получена от основната връзка в резултат на извършване на всички релационни изрази, наречени производственото съотношение.
118 Част I. Основни понятия
Забележка. В основните променливи съотношението се нарича променливи взаимоотношения.
Релационните системи очевидно трябва да осигурят средства за създаване, предимно основни променливи. В SQL, например, тази функция се осигурява от оператора за създаване на таблици (тук думата на масата се използва в тесен смисъл, като променлива връзка). Основните променливи взаимоотношения, разбира се, трябва да бъдат остър, като например, показани по-долу.
Създаване на таблица emp ...;
Въпреки това, релационните системи обикновено поддържат друг вид наречени променливи връзки представяния. Ввсеки определен момент, чиято стойност се получава съотношение (поради което се счита за опростено, че изпълнението е деривативна променлива връзка).Стойността на този поглед по това време е резултат от изчисляването на определен релационен израз в момента и споменатият релационен израз се определя по време на създаването на тази презентация. Например, за да определите представянето на Torrere, можете да използвате следното изявление.
Създайте виж торер като
(EMP, където заплата\u003e 3 3k
) (EMP #, понастоящем, заплата);
Забележка. Тъй като в момента е незначителен, в примера за удобство, смесена нотация на SQL езиците и ръководството D. се използва.
При извършване на този оператор, изразът по ключовата дума като и всъщност дефиниранене се изчислява, но се симулира от системата (обикновено чрез записване в директорията под определеното име на torreere). Въпреки това, от гледна точка на потребителя, всичко изглежда така, сякаш базата данни се появи много реална променлива връзка с nameammm, която има текущата стойност, която е показана на фиг. 3.7 само в неизброими зони. И потребителят трябва да може да работи с този поглед точно така, сякаш това е конвенционална променлива връзка на базата данни.
Фиг. 3.7. Виртуална променлива връзка Torrere (изключителни сайтове) като представителство на основната променлива на EMP връзката
Забележка. Вече е казано по-горе, че ако такива променливи взаимоотношения, Asdept и EMP могат да бъдат извикани, променливата връзка на уменията трябва да обмисли увреждания на връзката, с други думи, като променлива връзка, която външно съществува като такава, Но всъщност не е (тази стойност на тези променливи взаимоотношения във всеки един момент зависи от стойностите на някои
други променливи взаимоотношения). И наистина, в презентацията се нарича
виртуални варианти.
Въпреки това, бъдете внимателни: да се отбележи, че стойността на променливо съотношение torrere е отношение, което да доведе до резултат, ако изразът, определящ това представяне, всъщност е изчислен, ние не искаме да кажем, че има отделно копие на тези данни. С други думи, ние изобщо не означава, че изразът, който определя презентацията, наистина е изчислен. Напротив, гледната точка е по същество проста, чрез която човек може да види част от стойността на основната променлива на съотношението EMP. От това следва, че всички промени в основната променливи отношения ще влизат автоматично и незабавно въвеждат подобния прозорец (разбира се, ако тези промени са свързани с непроменена част от реалната променлива връзка). По същия начин промените, направени в променливата на темирното съотношение, ще бъдат автоматично и незабавно прилагани към реалното променливо съотношение на EMP и следователно ще бъдат видими чрез този прозорец (примерите ще бъдат дадени по-късно).
По-долу е даден пример за заявка, която използва изгледа на тора.
(Торере, където заплатата< 42К) { ЕМР#, SALARY }
Ако източникът използва данни на фиг. 3.7, резултатът ще бъде разгледан на фиг. 3.8.
Фиг. 3.8. Резултат от използването на представянето на Торере
От концептуална гледна точка на операциите с мнения, подобни на тези, които се считат по-горе, подобни на операциите по търсене, които действително се прилагат чрез замяна на позоваването на изгледа на израза, което определя представянето (т.е. изразът, запазен в директорията, е запазена в директорията ). Следователно, в разглеждания пример, първоначалното изразяване
(Торере, където заплатата< 42К) { ЕМР#, SALARY }
модифицирани от системата, както следва.
(((EMM, където заплатата\u003e zzk) (EME #, понастоящем, заплата)) Където заплатата.< 42К) { ЕМР#, SALARY }
Това предполага името на представянето в първоначалния израз и да се замени текста в модифицираната версия. След определен брой пренареждания този израз може да бъде опростен (глава 18) и е представен в следния формуляр.
(Където заплата EMM\u003e zzk и заплата< 42К) { ЕМР#, SALARY }
Изчисляването на този израз води до показания по-горе резултат. С други думи, първоначалната работа на презентацията се трансформира просто в еквивалентна операция на съответната базова връзка, след което
120 Част I. Основни понятия
еквивалентната операция се извършва по обичайния начин (по-точно оптимизиран и се извършва по обичайния начин).
Като друг пример, помислете за операцията за изтриване на изтриване.
Изтрийте Topemp, където заплатата< 42K ;
Всъщност ще се извърши следната операция.
Изтрийте EMP, където заплатата\u003e zzk и заплата< 42К;
Изследваният тук тест е много прост, състоящ се (експресиране на неформално) от подгрупа от редове и колони с една базова променлива връзка. По принцип обаче определението за представяне може да има произволна сложност(Може дори да се позове на други мнения). Например, освен това представлява определението, което включва връзката на две основни променливи.
Създайте виж Джонекс като
((EMP се присъедини към DEPT), където бюджетът\u003e 7м) (EMP #, dept #);
Ще се върнем към въпроса за определянето и преработката на представителства в глава 10. Между другото, вече е възможно да се обяснят смисъла на забележките, дадени в края на раздел 2.2 относно факта, че терминът представител (гледна точка) в отношенията Контекст има доста специфична стойност, която не съответства на стойността, ANSI / SPARC, приписан на него в архитектурата. На външното ниво на тази архитектура базата данни се възприема като външно представителствоопределената външна схема (и различни потребители могат да имат различни външни изявления). В релационните системи, напротив, гледната точка, както е обяснено по-горе, е специално наречена деривативна виртуална променлива връзка.Следователно, релационен аналог външно представителство
aNSI / SPARC обикновено обслужва разнообразие от няколко променливи взаимоотношения, всяка от които е презентация в релационен смисъл. Схемата се състои в идентифициране на такива представяния. (От това следва, че релационният модел е един от начините да се гарантира логическа независимост от данните,въпреки че трябва да се отбележи, че съвременните търговски продукти имат сериозни недостатъци в тази част. Подробности са дадени в глава 10.)
ANSI / SPARC архитектурата е доста често срещана и позволява произволни трансформации между външни и концептуални нива. По принцип дори и видовете структури на данни, поддържани от тези две нива, могат да бъдат различни: например, концептуално ниво може да бъде релационно, докато външното представяне на йерархичния тип може да бъде предадено на конкретен потребител. Въпреки това, на практика в повечето системи, същите видове структури се използват като основни на двете нива. Релационните продукти не са изключение от това общо правило - представянето все още е променлива връзка, както и основни променливи. И тъй като и двете нива се поддържат от същите видове обекти, тези нива използват същите субла на данните (обикновено е SQL езикът). Всъщност фактът, че гледната точка е променлива
5 Пример за тази възможност е даден в глава 27.
взаимоотношенията също са важни за релационните системи, тъй като за математиката е важно дадено подразбиране.
Забележка. Въпреки това, очевидно, в документацията за истинските SQL продукти и в самия SQL език, този нюанс често се игнорира (глава 4), тъй като често е възможно да се отговори на "таблиците и изявленията" (т.е. това предполага, че това Изглед не е таблица). Съветва да направи тази обща грешка и да използва терминалите (или променлива връзка)само за най-бързите таблици (или основни заместители).
Има още един въпрос за основните променливи на отношенията и идеите. Разликата между съотношението на основната променлива и представянето често се характеризира както следва.
■ Съотношението на основните променливи "наистина съществуват" в смисъл, че те са в собствени данни, които наистина се съхраняват в базата данни.
■ Напротив, "не съществуват", но просто предоставят лични начини за преглед на "реални" данни.
Въпреки това, тази характеристика, въпреки че е полезна в неофициален смисъл, неточно отразява истинското състояние на нещата. Всъщност, потребителите могат да разглеждат основните променливи отношения като физически съхранени, тъй като всъщност основната цел на създаването на релационни системи е да позволи на потребителя да работи с основните променливи на връзката като физически съществуващи, без да се тревожи за това как тези променливи са физически представени в памет. Но (и това е много важно ", но"!) Подобни възгледи за потребителите за това как се случва обработката на данните, е невъзможно да се тълкува така, сякаш основната променлива връзка се съхранява пряко в променливата връзка (например като единствен файл за съхранение ). Както е обяснено в раздел 3.2, основната променлива връзка е най-добре да се представлява зеле за определен набор от съхранени данни - абстракция, която крие всички части на нивата на съхранение. По принцип основното съотношение на променливите на Eeeoporand-Seamiventent6 може да се различава в непълнота.
Този въпрос ще помогне за изясняване на прост пример. Помислете отново за базата данни на отделите и служителите. В повечето съвременни релационни системи тя вероятно е била реализирана под формата на два съхранени файла, една за всяка променлива връзка на базата данни. Но няма абсолютно никакви аргументи срещу създаването на един запазен файл на йерархично съхранени записи, всеки от които се състои, на първо място, от номера на отдела, заглавията и бюджета за някой отдел, и второ, заедно с тях на масата Брой на служителя, фамилия и заплата на всеки служител, работещ в този отдел. С други думи, всеки подходящ метод може да се използва за физически съхраняване на данни (допълнителна информация е дадена в приложение А), но на логическото ниво данните трябва винаги да изглеждат еднакво.
6 Следващата цитат от една наскоро публикувана книга демонстрира някои недоразумения, обсъждани тук, както и недоразумения, които бяха обсъдени в раздел 3.3: "Важно е да се разграничат съхраняваните взаимоотношения, които са тайни, и виртуални отношения, които са представителства ...[Ние] Ние ще използваме термините само в случаите, когато можете да използвате термина "таблица" или "изглед" вместо това. Ако е необходимо да се подчертае, че това отношение е отношение на съхранението, а не от представянето, тогава в този случай ще използваме термина основно отношениеили основна маса. "Подобни кавички, за съжаление, не са необичайни.
