Всеки собственик на сайт знае, че за правилното функциониране на сайта са необходими не само файлове с код на страницата, но и бази данни. Системите за управление на бази данни (СУБД) се използват за взаимодействие с бази данни. В тази статия искам да говоря за бази данни и СУБД, за това какви разновидности съществуват и как те се различават един от друг.
База данни
Базата данни е специфичен набор от данни, които по правило са свързани чрез обединяваща характеристика или свойство (или няколко). Тези данни са сортирани, например, по азбучен ред. Изобилието от различни данни, които могат да бъдат поставени в една база данни, води до много вариации на това, което може да се записва: лични данни на потребителите, записи, дати, поръчки и т.н. Например, ако имате онлайн магазин, тогава базата данни на вашия уебсайт може да съдържа ценови листи, каталог на стоки или услуги, отчети, статистически данни и информация за клиенти.
На първо място, това е удобно, защото информацията може бързо да се въведе в базата данни и също толкова бързо да бъде извлечена, ако е необходимо. Ако в зората на развитието на уеб разработката всички необходими данни трябваше да бъдат записани в кода на страницата, сега няма такава необходимост - необходимата информация може да бъде поискана от базата данни с помощта на скриптове. Специални алгоритми за съхранение и извличане на информация, които се използват в бази данни, правят възможно намирането необходимата информациябуквално за части от секундата - и при работа в виртуално пространствоскоростта на ресурса е важна като нищо друго.
Връзката на информацията в базата данни също е важна: промяна в един ред може да доведе до значителни промени в други редове. Работата с данни по този начин е много по-лесна и по-бърза, отколкото ако промените се правят само на едно място в базата данни.
Това обаче не означава, че всеки сайт трябва да има база данни – например, ако имате сайт с визитка, и не нова информацияАко не публикувате на сайта, просто нямате нужда от база данни. Повечето лесен начиннаправете прост уебсайт - създайте .
Система за управление на база данни
Както може да се досетите от името, системата за управление на база данни (или накратко СУБД) е софтуер, който се използва за създаване и работа с бази данни. Главна функцияСУБД е управление на данни (което може да бъде както във външни, така и в оперативна памет). СУБД непременно поддържа езици на базата данни и също така отговаря за копирането и възстановяването на данни след всякакви неуспехи.
Що се отнася до класификацията на базите данни, има различни опции.
Например, можете да разделите основите на модели на данни: йерархичен (има дървовидна структура), мрежов (подобен по структура на йерархичната), релационен (използва се за управление релационни бази данниданни), обектно-ориентиран (използва се за обектен моделданни) и обектно-релационни (един вид сливане на релационния и обектно-ориентирания тип бази данни).
Или, ако разделението върви според къде се намира СУБД, те могат да бъдат разделени на локални - цялата СУБД е разположена на един компютър, и разпределени - части от системата за управление на базата данни са разположени на няколко компютъра.
Файл-сървър, клиент-сървър и вграден - такива имена са СУБД, ако ги разделите на метод за достъп до база данни. Включена СУБД на файлов сървър този моментвече се счита за остарял; основно се използва клиент-сървър (СУБД, които се намират на сървъра заедно със самата база данни) и вградени (не изискват отделна инсталация) системи.
Информацията, която се съхранява в бази данни, не е ограничена само до текстови или графични файлове - модерни версииСУБД също поддържа аудио и видео файлови формати.
В тази статия ще се съсредоточа върху СУБД, които се използват за съхраняване на информация от различни уеб ресурси.
Защо са необходими тези СУБД? В допълнение към основната им функция - съхраняване и организиране на огромно количество информация - те ви позволяват бързо да обработвате клиентски заявки и да издавате свежа и актуална информация.
Това важи и за промените, които правите – вместо да променяте информацията във всеки файл на сайта, можете да я промените в базата данни и тогава правилната информация ще се показва веднага на всяка страница.
Релационни СУБД и SQL език
Релационната и обектно-релационната СУБД са сред най-разпространените системи. Те са таблици, в които всяка колона (която се нарича "поле" или "поле") е подредена и има определено уникално име. Последователността от редове (те се наричат „записи“ или „записи“) се определя от реда, в който информацията се въвежда в таблицата. В този случай обработката на колони и редове може да се извърши в произволен ред. Таблиците с данни са свързани помежду си чрез специални връзки, поради които данните от различни масиможете да работите - например да ги комбинирате - с една заявка.
Използва се управление на релационна база данни специален езикпрограмиране - SQL. Съкращението означава „структуриран език за заявки“, преведено на руски „структуриран език за заявки“.
Командите, които се използват в SQL, са разделени на тези, които манипулират данни, тези, които дефинират данни, и тези, които манипулират данни.
Схемата на базата данни изглежда така:
MySQL
MySQL е една от най-популярните и широко разпространени СУБД, използвани от много компании (например Facebook, Wikipedia, Twitter, LinkedIn, Alibaba и други). MySQL е релационна СУБД, която принадлежи към свободния софтуер: разпространява се при условията на GNU Public License. По правило тази система за управление на база данни се определя като добра, бърза и гъвкава система, препоръчвана за използване в малки или средни проекти. MySQL има много различни предимства. Например, тя подкрепя различни видоветаблици: както добре познатите MyISAM и InnoDB, така и по-екзотичните HEAP и MERGE; освен това броят на поддържаните типове непрекъснато нараства. MySQL изпълнява всички команди бързо - може би сега това е най-бързата съществуваща СУБД. Неограничен брой потребители могат да работят с тази система за управление на база данни едновременно, а броят на редовете в таблиците може да бъде до 50 милиона.
Тъй като в сравнение с някои други MySQL СУБД поддържа по-малко функции, е много по-лесно да се работи с него, отколкото например с PostgreSQL, което ще бъде разгледано по-долу.
Първата версия на MySQL беше пусната през 1995 г. и оттогава има няколко последващи издания, всяка от които донесе значителни промени.
За работа с MySQL се използва не само текстов, но и графичен режим. Това е възможно благодарение на приложението phpMyAdmin: за да работите в приложението, дори няма да е необходимо да знаете SQL команди и можете да администрирате вашата база данни директно през браузъра.
Като цяло може да се отбележи, че MySQL е изборът на тези, които се нуждаят от СУБД за малък или среден проект, бърза и лесна за използване и без административни затруднения.
PostgreSQL
Тази свободно разпространена система за управление на база данни принадлежи към обектно-релационния тип СУБД. Както при MySQL, PostgreSQL е базиран на езика SQL, но за разлика от MySQL, PostgreSQL поддържа стандарта SQL-2011. Тази СУБД няма ограничения за максималния размер на базата данни, нито за максималните записи или индекси в таблицата.
Ако говорим за предимствата на PostgreSQL, тогава, разбира се, това е надеждността на транзакциите и репликации, възможността за наследяване и лесната разширяемост. PostgreSQL поддържа различни разширенияи варианти на език за програмиране като PL/Perl, PL/Python и PL/Java. Възможно е също зареждане на C-съвместими модули.
Мнозина отбелязват, че за разлика от MySQL, тази СУБД има добра и подробна документация, която отговаря на почти всички въпроси.
Фактът, че това е по-мащабна СУБД от MySQL, се доказва и от факта, че PostgreSQL периодично се сравнява с такива мощна системауправление на данни като Oracle.
Всичко това ни позволява да говорим за PostgreSQL като за една от най-модерните СУБД в момента.
SQLite
В момента е една от най-компактните СУБД; също така е вграждаем и релационен. SQLite ви позволява да съхранявате всички данни в един файл и поради малкия си размер има завидна скорост. SQLite се различава значително от MySQL и PostgreSQL по своята структура: двигателят и интерфейсът на тази СУБД са в една и съща библиотека - и това ви позволява да изпълнявате всички заявки много бързо. Други СУБД (MySQL, PostgreSQL, Oracle и др.) използват парадигмата клиент-сървър, когато взаимодействието се осъществява чрез мрежов протокол.
Сред недостатъците може да се отбележи липсата на потребителска система и възможността за увеличаване на производителността.
SQLite може да се препоръча за използване в проекти, където трябва да можете бързо да пренесете приложението и няма нужда от мащабируемост.
Оракул
Тази СУБД принадлежи към обектно-релационния тип. Името идва от името на компанията Oracle, разработила тази система. Заедно със SQL, СУБД използва процедурно разширение, наречено PL/SQL, както и езика Java.
Oracle е система, която е стабилна повече от дузина години, така че това е изборът на големите корпорации, за които надеждното възстановяване след повреди, рационализираната процедура за архивиране, мащабируемостта и други ценни функции са важни. В допълнение, тази СУБД осигурява отлична сигурност и ефективна защита на данните.
За разлика от други СУБД, разходите за закупуване и използване на Oracle са доста високи и това често е значителна пречка за използването му в малки фирми. Вероятно това е и причината Oracle да е едва на 6-то място в рейтинга на СУБД за 2016 г. в Русия.
MongoDB
Тази СУБД е различна по това, че е предназначена за съхранение йерархични структуриданни и затова се нарича документно-ориентиран (това е хранилище за документи без използване на таблици или схеми). MongoDB е с отворен код.
С помощта на идентификатор можете да извършвате бързи операции върху обект; тази СУБД се представя добре при сложни взаимодействия. На първо място, говорим за скорост - в някои случаи приложение, написано в MongoDB, ще работи по-бързо от същото приложение, използващо SQL, т.к. MongoDB принадлежи към класа NoSQL DBMS и използва език за заявки за обекти вместо SQL, който е много по-лек от SQL.
Този език обаче има своите ограничения и затова MongoDB трябва да се използва в случаите, когато няма нужда от сложни и нетривиални селекции.
Вместо заключение
Изборът на СУБД е важен моменткогато създавате своя ресурс. Започнете от вашите задачи и възможности, опитайте се и експериментирайте, за да намерите точно варианта, който ще бъде най-подходящ.
Изграждане на релационни бази данни
Основи на изграждането на релационни бази данни
Описание на релационни данни
В процеса на изграждане на релационна база данни трябва да се решат няколко проблема. Първо е необходимо да се опише структурата на базата данни за СУБД. За да направи това, разработчикът използва език за описание на данни или някакъв еквивалентен начин за описание на структурата (например графичен дисплей). След това базата данни се записва на някаква форма на физически носител и се попълва с данни. В този раздел ще разгледаме всяка една от тези задачи, но първо нека разгледаме релационната терминология.
Преглед на терминологията
Както е посочено в глава 5, поведениее таблица с определени свойства.
Записите в релация могат да имат само единични стойности; множество стойности не са разрешени. Следователно има само една стойност в пресечната точка на ред и колона.
Всички записи в една и съща колона са от един и същи тип. Например една колона може да съдържа имената на клиентите, а другата датите на раждане. Всяка колона има уникално име, а редът на колоните не е важен. Колоните на релациите са именувани атрибути.Всеки атрибут има свой собствен домел,което е физическо и логическо описание на набора от валидни стойности.
3. В една връзка не може да има два еднакви реда и редът на редовете не е важен (фиг. 8.1). Линиите на връзката също се наричат кортежи.
Рисуване 8.1 е пример или единичен екземпляр на релационна структура, съдържаща информация за пациент в клиниката. обобщен формат, ТЪРПЕЛИВ (име, РажданеДата, Пол, Номер на сметка, лекар) е структурата на връзката; това е, което повечето хора имат предвид под термина отношение.(помнете от гл 5, че атрибутът, който е ключът на релацията, е подчертан.) Ако добавим ограничение за възможните стойности на данните към структурата на релацията, получаваме релационна схема(релационна схема). Всички тези термини са дадени в табл. 8.1.
Недоразумения относно термина "ключ"
Срок ключчесто е източник на объркване, тъй като има различни значения на етапите на проектиране и изпълнение. В процеса на проектиране под ключ се разбира една или повече колони, които уникално идентифицират ред за връзка. Както знаем от гл 5, всяка релация има поне един ключ, тъй като всеки ред е уникален; в граничния случай ключът е комбинация от всички колони на релацията. Обикновено ключът се състои от една или две колони.
В срок на изпълнение ключизползван в различно значение. В повечето релационни СУБД ключът е колона, на базата на която СУБД генерира индекс и други структури от данни. Това се прави, за да се гарантира бърз достъпкъм стойностите в тази колона. Тези ключове не трябва да са уникални и често наистина не са. Те са създадени само за подобряване на производителността. (За информация относно такива структури от данни вижте Приложение А.)
Помислете например за връзката ПОРЪЧКА (Номер на поръчка, Дата на поръчка, Номер на клиента, Количество).От гледна точка дизайн,ключът към тази връзка е Номер на поръчка,защото селекцията удебеленоозначава, че този атрибут уникално идентифицира низа на връзката. От гледна точка изпълнение,ключът може да бъде всяка от четирите колони на дадената релация. Може да бъде например атрибут Дата на поръчка. VВ този случай СУБД ще създаде структура от данни, която осигурява бърз достъп до данните от релацията ПОРЪЧКАпо стойност на датата на поръчката. Вероятно за конкретна стойност на атрибута Дата на поръчкаще съответства на много линии. VВ този смисъл дефинирането на атрибут като ключ не говори нищо за неговата уникалност.
Понякога, за да се направи разлика между две значения на една дума ключ,се използват термини логически ключ(логически ключ) и физически ключ(физически ключ). Логическият ключ е уникален идентификатор, докато физическият ключ е колона, върху която е създаден индекс или друга структура от данни за подобряване на производителността.
Индекси
Тъй като физическият ключ обикновено е индекс, някои напускат термина ключстойността на логическия ключ и зад термина индекс- смисъл физически ключ. VВ тази книга ще направим точно това: терминът ключще използваме в значението на "логически ключ" и термина индекс -което означава "физически ключ".
VИма три причини за създаване на индекси. Един от тях е да осигури бърз достъп до редове чрез индексирана стойност на атрибута. Друго е да се улесни сортирането на редове по този атрибут. Например, vуважение ПОРЪЧКАатрибут може да бъде дефиниран като ключ Дата на поръчка,което води до доклади vкоито поръчки са сортирани по дата ще се генерират по-бързо.
Третата цел на изграждането на индекси е да осигури уникалност. Индексите не трябва да са уникални, но когато разработчикът иска колона да бъде уникална, СУБД създава индекс за тази колона. В повечето релационни СУБД колона или група от колони могат да бъдат направени уникални чрез посочване на ключовата дума при дефиниране на колона в таблица. УНИКАЛЕН.
Внедряване на релационна база данни
И в тази книга използваме релационния модел, за да опишем структурата на базата данни. Следователно, от проектирането на базата данни, можем директно да преминем към нейното изпълнение. Не е необходимо по никакъв начин да променяме структурата на внедряване: всичко, което трябва да направим, е да опишем съществуващата релационна структура към СУБД.
При внедряване на бази данни с помощта на нерелационна СУБД ситуацията е различна. Например, когато внедряваме база данни на базата на DL/I модела, трябва да преобразуваме релационната структура в йерархична и след това да опишем трансформираната структура в СУБД.
Описание на структурата на базата данни за СУБД
Има няколко начина, по които структурата на базата данни се описва за СУБД. Тези методи зависят от това коя конкретна СУБД се използва. 13 Някои продукти създават текстов файл, който описва структурата на базата данни. Езикът, използван за дефиниране на такава структура, понякога се нарича език за дефиниране на данни(език за дефиниране на данни, DDL). Текстовият DDL файл изброява имената на таблиците на базата данни, посочва имената на колоните на тези таблици и описва тяхното съдържание, дефинирани са индекси, както и други структури (ограничения, мерки за сигурност). Списък 8.1 описва проста релационна база данни за хипотетична СУБД, използваща типичен език за дефиниране на данни. По-реалистични примери, използващи стандарт, наречен SQL, са дадени в глави 12 и 13.
Някои СУБД не изискват структурата на базата данни да се дефинира с помощта на DDL in текстов формат. Най-често срещаната алтернатива е графичен начинзадаване на структурата на базата данни. Например в Access 2002 на разработчика се дава графична структура под формата на списък, на подходящите места на който трябва да въведете имената на таблици и колони. Видяхме пример за това в Глава 2 (вижте Фигура 2.2).
Общо казано, графични помощни средстваОписанията на данни са често срещани в СУБД, предназначени да работят на персонални компютри. На сървърите и мейнфрейм компютрите се използват както графични, така и текстови средства. Например Oracle и SQL Server могат да използват и двата метода за дефиниране на данни. На фиг. 8 .2 представени обща схемапроцесът на описване на данни за СУБД.
При двата начина на дефиниране на структурата на данните, разработчикът трябва да наименува всяка таблица, да дефинира колоните за тази таблица и да опише физическия формат на данните във всяка колона (да речем, ТЕКСТ 10). Освен това, в зависимост от възможностите на използваната СУБД, разработчикът може да посочи ограниченията, които трябва да се прилагат от СУБД. Стойностите на колоните могат да бъдат дефинирани например като НЕНУЛА(не е празен) или УНИКАЛЕН(уникален). Някои продукти също ви позволяват да зададете ограничения на възможните стойности (атрибут частможе да приема стойности по-малки от 10 000, и атрибута Цвятможе да приеме една от стойностите [„Червено“/Зелено“/Синьо“]).И накрая, могат да бъдат въведени ограничения за целостта на външния ключ. Ето пример за такова ограничение: „Стойност на атрибута Номер на отделна масата СЛУЖИТЕЛтрябва да е равно на стойността на атрибута Номер на отделна масата ОТДЕЛЪТ".
В много СУБД разработчикът може също да задава пароли и да използва други контроли и сигурност. Както ще бъде показано в главата 11, има много различни стратегии за сигурност. В някои стратегии обектите на контрол са структури от данни (например таблицата е защитена с парола), в други - потребители (собственикът на паролата X може да чете и актуализира таблици T1и Т2).
Разпределение на пространството на физически носител
В допълнение към дефинирането на структурата на базата данни, разработчикът трябва да разпредели място за базата данни на физически носител. Отново, точните стъпки зависят от това коя СУБД се използва. Кога лична база даннивсичко, което трябва да направите, е да дадете на базата данни директория на диска и да й дадете име. След това СУБД автоматично ще разпредели място за съхранение на данни.
Други СУБД, особено тези за сървъри и мейнфреймове, изискват повече усилия. За да подобрите производителността и контрола, трябва внимателно да проектирате разпределението на информацията в базата данни между дискове и канали. Например, в зависимост от това как се обработват приложенията, може да е по-добре да поставите определени таблици на един и същ диск. Обратно, може да е важно някои таблици да не се намират на един и същи диск.
Помислете например за обект на поръчка, съставен от таблици ORDER, ORDER_LINEи ПРОДУКТ.Да приемем, че при обработка на поръчка приложението чете един ред от таблицата ПОРЪЧКА,няколко реда от таблица ORDER_STRINGи един ред от таблицата ПРОДУКТза всеки ред от таблицата ORDER_STRING.След това редове от таблицата ORDER_LINE,свързани със същия ред обикновено се групират заедно, а редовете в таблицата ПРОДУКТне са групирани по никакъв начин. Тази ситуация е илюстрирана на фиг. 8.3.
Сега си представете, че организацията обработва много поръчки паралелно и че има два диска: единият голям и бърз, а другият по-малък и по-бавен. Разработчикът трябва да определи най-доброто място за съхранение на данните. Може би производителността ще се подобри, ако таблицата ПРОДУКТще се съхранява на голям диск с бърз достъп и таблици ORDER_STRINGи ПОРЪЧКА- на диск по-малък и по-бърз. Или може би производителността ще бъде по-висока, ако поставите данни от таблици ПОРЪЧКАи ORDER_STRINGза предходни месеци на по-бавно движение, а за текущия месец на по-бързо.
Тук не можем да отговорим на тези въпроси, защото отговорът зависи от количеството данни, характеристиките на СУБД и операционната система, размера и скоростта на дисковете и каналите и изискванията на приложенията, използващи базата данни. Въпросът е, че всички тези фактори трябва да се вземат предвид при разпределянето на място за база данни на физически носител.
В допълнение към местоположението и количеството пространство за потребителски данни, разработчикът може също да трябва да посочи дали пространството трябва да нараства според нуждите и ако е така, с колко. По правило размерът на такова увеличение се посочва или като фиксирана стойност, или като процент от първоначалното количество заето пространство.
Когато създава база данни, разработчикът ще трябва да разпредели файлово пространство за регистрационните файлове на базата данни. Ще научите за воденето на дневник в глави 11-13; на този етап просто трябва да знаете, че СУБД поддържа дневник на промените в базата данни, който след това, ако е необходимо, може да се използва за възстановяване на базата данни. Файловото пространство за регистрационни файлове се разпределя по време на фазата на създаване на база данни.
Създайте план за поддръжка на база данни
Планът за поддръжка на база данни е график от процедури, които трябва да се извършват редовно. Тези процедури включват архивиранебаза данни, изхвърляйки съдържанието на входа в базата данни архивни файлове, проверка за нарушения на референтната цялост, оптимизиране на дисковото пространство за потребителски данни и индекси и т. н. Ще разгледаме и тези проблеми в глава 11, но имайте предвид, че план за поддръжка на база данни трябва да бъде създаден по време на процеса на създаване или скоро след него .
Попълване на базата данни с информация
След като базата данни е дефинирана и пространството е разпределено за нейното съхранение на физически носител, можете да започнете да попълвате базата данни с информация. Начинът, по който това става зависи от изискванията на приложенията и възможностите на СУБД. В най-добрия случай всички данни вече са в компютърно четим формат, а СУБД има функции и инструменти за опростяване на импортирането на данни от магнитни носители. В най-лошия случай всички данни трябва да се въвеждат ръчно чрез клавиатурата с помощта на приложни програми, създадени от разработчиците от нулата. Повечето ситуации, при които е необходимо преобразуване на данни, попадат някъде между тези две крайности.
При въвеждане на данните е необходимо да се провери тяхната коректност. Тази проверка е досадна и трудоемка, но е много важна. Често, особено в големи бази данни, има смисъл да се пишат специални програми за валидиране на данни. Ползите от използването на тези програми ще се отплатят добре времето и парите, изразходвани от екипа за разработка, за да ги създаде. Такива програми се занимават с преброяване на броя на редовете в различни категории, изчисляване на контролни суми, извършване на проверки за валидиране на стойностите на данните и други процедури за контрол.
Манипулиране на релационни данни
Обсъдихме дизайна на релационни бази данни и начините, по които се описва структурата на база данни за СУБД. Досега, когато говорим за релационни операции, ние мислихме по обобщен и интуитивен начин. Този начин е добър, стига да е проект, но за да приложим приложения, се нуждаем от ясен и последователен език, който изразява логиката на обработката. Такива езици се наричат езици за манипулиране на danpshi(езици за манипулиране на данни, DML).
Към днешна дата са предложени четири стратегии за манипулиране на релационни данни. Първата от стратегиите релационна алгебра(релационна алгебра), дефинира оператори, действащи върху релации (те са подобни на операторите от по-висока алгебра +, - и т.н.). Тези оператори ви позволяват да манипулирате връзките за постигане желания резултат. Но релационната алгебра е трудна за използване, отчасти защото е процедурна. Това означава, че при използване релационна алгебратрябва да знаем не само Каквоправим, но също така както се прави.
Релационната алгебра не се използва в търговски системи за обработка на бази данни. Въпреки че нито една комерсиално успешна СУБД не включва инструментариум за релационна алгебра, ние ще го обсъдим тук, защото ще ви помогне да разберете по-ясно манипулирането на релационни данни и ще положи основата за изучаване на SQL.
релационно смятане(релационно смятане) е втората стратегия за манипулиране на релационни данни. Релационното смятане не е процедурно; това е език, който изразява Каквоискаме да направим, без да уточняваме какпостигне това. Запомнете интегриращата променлива в интегралното изчисление: тази променлива взема стойности от диапазона, в който се извършва интегрирането. Подобна променлива има в релационното смятане. В кортежно-релационното смятане обхватът на тази променлива са кортежи на релацията, докато в релационното смятане на домейн, стойностите на домейна. Релационното смятане се основава на клон от математиката, наречен предикатно смятане.
Ако няма да ставате теоретик на релационните технологии, вероятно няма да е необходимо да изучавате релационни смятане. Той никога не се използва в търговски системи за бази данни и не е необходим за нашите цели. Затова няма да го обсъждаме в тази книга.
Въпреки че релационното смятане е трудно за разбиране и използване, неговото непроцедурно естество е предимство. Затова разработчиците на СУБД започнаха да търсят други непроцедурни стратегии, което доведе до появата на третата и четвъртата категории езици за манипулиране на релационни данни.
Езиците, ориентирани към трансформацията, са клас от непроцедурни езици, които трансформират вход, който е под формата на релация, в резултат, който е единична релация. Тези езици имат лесни за използване структури, които ви позволяват да посочите действията, които да предприемете с предоставените данни. SQUARE, SEQUEL и SQL са примери за езици, ориентирани към трансформация. SQL езикще бъдат разгледани подробно в глави 9, 12 и 13.
Четвъртата категория езици за манипулиране на релационни данни са графичните езици. Тази категория включва примерна заявка(Запитване по пример) и заявка за формуляр(Запитване по формуляр). Продуктите, поддържащи тази категория, включват Approach (от Lotus) и Access. На потребителя се представя графично представяне на една или повече връзки. Изгледът може да бъде формуляр за въвеждане на данни, електронна таблица или някаква друга структура. СУБД трансформира изгледа в съответната релация и генерира заявки (най-вероятно в SQL) от името на потребителя. След това потребителите започват изпълнението на DML оператори, без да знаят това. Четирите категории езици за манипулиране на релационни данни са:
релационна алгебра;
релационно смятане;
езици, ориентирани към трансформация (например SQL);
примерна заявка, заявка за формуляр.
Езикови интерфейси за манипулиране на данни
В този раздел ще разгледаме четири вида интерфейси, чрез които се манипулира информацията в база данни.
Манипулиране на данни чрез формуляри
Повечето релационни СУБД имат инструменти за създаване на формуляри. Някои формуляри се генерират автоматично, когато таблицата е дефинирана, други трябва да бъдат създадени от разработчика. Помощ в този процес може да бъде предоставена от интелигентен асистент, присъстващ например в Access. Формулярът може да бъде под формата на таблица (електронна таблица), в която едновременно се показват няколко релационни линии. Има и друг вид формуляри, при които всяка линия на връзката се представя отделно. На фиг. Фигури 8.4 и 8.5 показват примери за двата типа формуляри за таблицата ПАЦИЕНТ на фиг. 8.1. Повечето продукти осигуряват известна гъвкавост при работа с формуляри и отчети. Например, редовете, които трябва да бъдат обработени, могат да бъдат избрани по стойности на колони и могат да бъдат сортирани. Таблица на фиг. 8.4 се сортира по стойността на полето AccountNumber.
Много формуляри, генерирани по подразбиране, съдържат данни само от една релация. Ако трябва да получите данни от две или повече връзки, тогава обикновено трябва да създадете специални формуляри с помощта на инструменти на СУБД. Такива инструменти ви позволяват да създавате както многотаблици, така и многоредови формуляри. Тъй като използването на тези инструменти е силно зависимо от конкретната СУБД, ние няма да ги разглеждаме допълнително.
Запитване и актуализиране на езиков интерфейс
Вторият тип интерфейс към базата данни е език за запитване и актуализиране(език на заявка/актуализация) или просто език на заявката(език на заявките). (Въпреки че повечето от тези езици позволяват както заявка, така и актуализиране на данни, те най-често се наричат езици за заявки.) В този случай потребителят въвежда команди, които определят какви действия да извърши в базата данни. СУБД декриптира тези команди и изпълнява предписаните действия. Фигура 8.6 показва кои програми участват в обработката на заявката.
Най-важният от всички езици за заявки е SQL. За да ви дадем представа за езиците на заявки, разгледайте следния SQL израз, който обработва релация ТЪРПЕЛИВ, показано на фиг. 8.1:
ИЗБЕРЕТЕ Име. Дата на раждане ОТ ПАЦИЕНТ
КЪДЕ Лекар = "Леви"
Този оператор извлича от релацията ТЪРПЕЛИВвсички редове, в които атрибутът лекарима смисъл " Леви". Стойности на атрибути имеи Дата наРажданеот тези редове след това се поставя във втора таблица.
Съхранени процедури
С течение на времето потребителите на база данни и разработчиците са открили, че определени поредици от SQL команди трябва да се изпълняват редовно. Единственото, което се променя, са стойностите, посочени в офертата. КЪДЕТО. Например, при месечно таксуване се изпълняват едни и същи SQL оператори, но с различна крайна дата. За да отговорят на тази нужда, доставчиците на СУБД са въвели т.нар съхранени процедури(запазени процедури). Такава процедура представлява набор от SQL оператори, които се съхраняват във файл и могат да бъдат стартирани за изпълнение с една команда. Параметри посочени в офертата КЪДЕТОи т.н. може да се предава при извикване на процедура. Пример би бил следният:
НАПРАВЕТЕ ТАКСУВАНЕ STORED_PROCEDURE ЗА BILLDATE = "9/1/2000"
Този ред стартира съхранена процедура, наречена ТАКТУРАНЕсъс стойност на параметъра ДАТА НА РАБОТА, равно на "9/1/2000".
Тъй като разработчиците натрупаха опит, се появи един проблем. SQL е създаден като подезик за данни и не е направен опит да бъде надарен с всички елементи на пълноправен език за програмиране. Някои от тези елементи обаче бяха необходими за писане на съхранени процедури и доставчиците на бази данни създадоха разширени версии на SQL, за да включват допълнителни функции. Един такъв език, PL/SQL, е разработен за Oracle, а друг, наречен TRANSACT-SQL, е разработен за SQL Server. Ще научите повече за тези езици в глави 12 и 13.
Специален тип съхранена процедура - задействане(тригер) - извиква се от СУБД, когато е изпълнено посоченото условие. Например, в приложение за обработка на поръчки, разработчикът трябва да създаде тригер, който се задейства, когато количеството на артикул в склада е под дадено ограничение (тоест е време да поръчате артикул от доставчик на едро). Ще научите повече за съхранените процедури в глави 12 и 13.
Интерфейс на приложната програма
Четвъртият тип интерфейс за достъп до данни е достъп чрез приложни програми, написани на езици за програмиране като COBOL, BASIC, Perl, Pascal и C++. Освен това някои приложни програми са написани на езици, вградени в използваната СУБД. От тези езици за програмиране, dBASE е най-известният.
Има два стила на интерфейс между приложните програми и СУБД. Първият от тях се характеризира с факта, че приложните програми извикват подпрограми от библиотеката с функции, предоставена с СУБД. Например, за да прочете ред от таблица, приложението извиква функцията за четене на СУБД и й предава параметри, които определят желаната таблица, задължителните колони, критерии за избор на ред и т.н.
В някои случаи вместо извиквания на функции се използва обектно-ориентиран синтаксис. В кода за достъп по-долу указателят на обект db е зададен на текущо отворената база данни, а указателят на обекта rsсе отнася до редовете на таблицата ТЪРПЕЛИВ;
setdb=currentdbC)
задайте rs = db.OpenRecordsetCPATIENT")
С помощта на последния показалец можете да получите достъп до свойствата на openот този набор от записи и стартирайте неговите методи. Например, използвайки свойствотоrs. Разрешаване на изтриваниявъзможно е да се определи дали записите могат да бъдат премахнати от набор от записи ТЪРПЕЛИВ. Метод MoveFirstпремества курсора на първия ред.
Второ, повече стар типинтерфейсът понякога се използва в СУБД, предназначени за мейнфреймове и сървъри. Тук производителят на СУБД дефинира набор от команди за достъп до данни от високо ниво. Тези команди, които са свързани с обработката на база данни и не са част от никакъв стандартен език, са вградени в кода на приложението.
Приложната програма с вградени команди се прехвърля към предварителния компилатор, включен в пакета на СУБД. Той превежда изразите за достъп до данни в валидни извиквания на функции и дефинира областите с данни, които да се споделят между приложните програми и СУБД. Предкомпилаторът също така вмъква код в програмата, която поддържа достъп до тези региони с данни. Обработената по този начин програма се прехвърля в езиковия компилатор. На фиг. 8 .7 показва взаимодействието на програмите в този процес.
Въведение
Глава 1. Основи на базата данни
1.1.Класификация на базите данни
1.3 Модели за описание на бази данни
1.4. Основи на настолната СУБД
1.5.Изисквания и стандарти за бази данни
Глава 2. Работа с базата данни Microsoft Access
2.1. Основи на настолната база данни Microsoft Access
2.2. Работа с база данни на Microsoft Access
Заключение
Списък на използваната литература
Въведение
Потоците от информация, които циркулират в света, който ни заобикаля, са огромни. В
време, те са склонни да се увеличават. Следователно във всяка организация
големи и малки, има проблем на такава организация на управление
данни, които биха предоставили най-много ефективна работа. някои
организациите използват картотеки за това, но повечето предпочитат
компютъризирани методи - бази данни, които ви позволяват ефективно да съхранявате,
структурирайте и организирайте големи количества данни. И днес без бази
данни е невъзможно да си представим работата на повечето финансови, индустриални,
търговски и други организации. Ако нямаше бази данни, те просто щяха да се задавят
информационна лавина.
Има много добри причини за прехвърляне съществуваща информацияна компютърна основа. Сега разходите за съхранение на информация в компютърни файлове са по-евтини, отколкото на хартия. Базите данни ви позволяват да съхранявате, структурирате информация и да извличате
оптимален за потребителя. Тази темае актуален в момента, т.к използването на клиент/сървър технологии ви позволява да спестите значителни средства и най-важното време за получаване необходимата информация, както и опростяват достъпа и поддръжката, тъй като се основават на сложна обработка на данни и централизиране на тяхното съхранение. Освен това компютърът ви позволява да съхранявате всякакви формати на данни, текст, чертежи, ръкописни данни, снимки, гласови записи и т.н.
За да се използват такива огромни количества съхранявана информация, в допълнение към разработването
необходими са системни устройства, средства за предаване на данни, памет, средства
осигуряване на диалог човек-компютър, който позволява на потребителя да влезе
или вземайте решения въз основа на съхранени данни. За предоставяне на тези функции
създадена специализирани средства– системи за управление на бази данни (СУБД).
Целта на тази работа е да разкрие концепцията за база данни и система за управление на база данни, както и да разгледа конкретен примерработа на настолна СУБД.
1.1.Класификация на базите данни
Базата данни е информационен модел предметна област, колекция от свързани данни, съхранявани заедно с минимално излишък, така че да може да се използва оптимално за едно или повече приложения. Данните (файловете) се съхраняват във външна памет и се използват като входна информацияза решаване на проблеми.
СУБД е програма, която внедрява централизирано управлениеданни, съхранявани в базата данни, достъп до тях, поддържане на актуални.
Системите за управление на бази данни могат да бъдат класифицирани според метода за установяване на връзки между данните, естеството на функциите, които изпълняват, обхвата на приложение, броя на поддържаните модели на данни, естеството на езика, използван за комуникация с базата данни, и други параметри.
Класификация на СУБД:
· Според изпълняваните функции СУБД се делят на оперативни и информационни;
· според обхвата на приложение СУБД се делят на универсални и проблемно-ориентирани;
Според използвания език на комуникация СУБД се делят на затворени, имащи собствени независими езицикомуникация на потребители с бази данни, и отворена, в която се използва език за програмиране за комуникация с базата данни, разширен от оператори на език за манипулиране на данни;
· Според броя на поддържаните нива на модели на данни СУБД се разделят на едно-, дву-, тристепенни системи;
според метода за установяване на връзки между данни, релационни, йерархични и мрежови базиданни;
· според начина на организиране на съхранение на данни и изпълнение на функциите по обработка базите данни се делят на централизирани и разпределени.
Централизирани системи за бази данни с достъп до мрежатаИма две основни архитектури - файлов сървър или клиент-сървър.
Архитектура на файлов сървър.Предполага избора на една от мрежовите машини като централна ( основен сървърфайлове), където се съхранява споделена централизирана база данни. Всички други машини действат като работни станции. Файловете на базата данни в съответствие с потребителските заявки се прехвърлят към работни станции, където се обработват основно. С висока интензивност на достъп до същите данни, производителност информационна системапада.
Архитектура клиент-сървър.Този модел на взаимодействие между компютрите в мрежа всъщност се превърна в стандарт за съвременната СУБД. Всеки от компютрите, свързани към мрежата и съставляващи тази архитектура, играе роля: сървърът притежава и управлява информационни ресурсисистеми, клиентът има възможност да ги използва. В допълнение към съхраняването на централизираната база данни, сървърът на базата данни обработва по-голямата част от обработката на данни. Заявка за данни, издадена от клиента (работната станция), генерира търсене и извличане на данни на сървъра. Извлечените данни се транспортират през мрежата от сървъра до клиента. Спецификата на архитектурата клиент-сървър е използването на SQL език за заявки.
Сървърът на базата данни е СУБД, която едновременно обработва заявки от всички работни станции. По правило клиентът и сървърът са географски разделени един от друг, като в този случай те образуват разпределена система за обработка на данни.
1.2. Функционалност на СУБД
Характеристиките на СУБД са:
производителност;
Осигуряване на целостта на данните на ниво база данни;
Осигуряване на сигурност на данните;
Възможност за работа в многопотребителска среда;
Възможност за импортиране и експортиране на данни;
Предоставяне на достъп до данни с помощта на езика SQL;
Възможност за отправяне на заявки
Наличие на инструменти за разработване на приложни програми.
Производителността на СУБД се оценява:
Времето, необходимо за изпълнение на заявките
скоростта на извличане на информация;
време на импортиране на бази данни от други формати;
скоростта на операциите (като актуализиране, вмъкване, изтриване);
време на генериране на отчета и други показатели.
Сигурността на данните се постига:
Криптиране на приложни програми;
криптиране на данни;
защита на данните с парола;
· ограничаване на достъпа до базата данни (до таблица, до речник и др.).
Осигуряване на целостта на данните предполага наличието на средства, които да гарантират, че информацията в базата данни винаги остава вярна и пълна. Целостта на данните трябва да се поддържа независимо от това как данните се въвеждат в паметта (онлайн, чрез импортиране или чрез специална програма). Използваните в момента СУБД разполагат със средства за осигуряване на целостта на данните и надеждна сигурност.
Системата за управление на базата данни управлява данни във външна памет, осигурява надеждно съхранение на данни и поддръжка за съответните езици на базата данни. Важна функция на СУБД е функцията за управление на RAM буферите. Обикновено СУБД работят с бази данни големи размери, често надвишаващи размера на основната памет на компютъра. Разработените СУБД поддържат свой собствен набор от RAM буфери със собствена дисциплина за подмяната им.
Най-широко използваните системи за управление на бази данни са Microsoft Access и Oracle.
Етапите на работа в СУБД са:
създаване на структурата на базата данни, т.е. дефиниране на списъка с полета, които съставляват всеки запис на таблицата, видове и размери на полета (числови, текстови, логически и др.), дефиниране на ключови полета за осигуряване на необходимите връзки между данни и таблици;
Въвеждане и редактиране на данни в таблици на базата данни с помощта на стандартния формуляр, представен по подразбиране под формата на таблица и използване на екранни формуляри, специално създаден от потребителя;
обработка на данни, съдържащи се в таблици въз основа на заявки и на базата на програмата;
· извеждане на информация от компютъра с използване на отчети и без използване на отчети.
Тези етапи на работа се изпълняват с помощта на различни команди.
Централизираната база данни осигурява лекота на управление, по-добро използване на данните в полето при извършване на отдалечени заявки и др висока степенедновременна обработка, по-ниски разходи за обработка.
Разпределената база данни включва съхранение и изпълнение на функции за управление на данни в няколко възли и прехвърляне на данни между тези възли в процеса на изпълнение на заявки. В такава база данни могат да се съхраняват не само различните й таблици различни компютри, но и различни фрагменти от една и съща таблица. В същото време за потребителя няма значение как е организирано съхранението на данни, той работи с такава база данни като с централизирана.
1.3 Модели за описание на бази данни
Известни са три типа модели на описание на бази данни – йерархични, мрежови и релационни, като основната разлика между които е естеството на описанието на връзките и взаимодействието между обектите и атрибутите на базата данни.
Йерархичен моделвключва използването на дървовидни структури, състоящи се от определен брой нива за описване на базата данни. „Дървото“ е йерархия от елементи, наречени възли. Елементите се разбират като списък, колекция, набор от атрибути, елементи, които описват обекти.
Базата данни е колекция от структурирани и взаимосвързани данни, свързани с конкретна предметна област.
За създаване, съхранение, обработка и колективно използване на информация, специални софтуерни системинаречени системи за управление на бази данни (СУБД).
Основните функции на СУБД включват следното:
физическо подреждане на данните и техните описания в паметта;
Поддържане на бази данни актуални
механизми за търсене на исканите данни;
· достъп до данни с едновременно искане на едни и същи данни от много потребители (приложни програми);
· начини за защита на данните от неправилни актуализации и/или неоторизиран достъп.
Основната характеристика на СУБД е наличието на процедури за въвеждане и съхранение не само на самите данни, но и на описания на тяхната структура.
Внимателният дизайн на базата данни е първият и много важна стъпкасъздаване на база. Той избягва разходите, свързани с извършването на корекции в структурата на съхраняваните данни. Проектирането на база данни започва с анализ на предметната област и идентифициране на изискванията към нея от отделни потребители (служители на организацията, за която се създава базата данни). На етапа на проектиране се идентифицират информационните обекти и техните характеристики, определят се видовете данни, които изискват редовни актуализации, и се формулират начини за представяне на информация на екрана и в отчети, формулират се въпроси, на които трябва редовно да се отговаря при търсене на данни . Това помага да се уточнят изискванията за съхраняваната информация. По всяко време можете да промените структурата на информацията, съхранявана в базата данни, като коригирате структурата на таблиците и съответно на формулярите и отчетите. Администраторът на база данни (DBA) е отговорен за проектирането и поддържането на базата данни.
СУБД използва следните моделии описания:
· инфологически;
· логически данни;
физически.
Тристепенна архитектура(инфологични, логически и физически нива) ви позволява да гарантирате независимостта на съхраняваните данни от програмите, които ги използват.
Първоначално се създава обобщено неформално описание създадена базаданни. Това описание се нарича инфологически модел на данни и се прави с помощта на естествен език, блок-схеми, математически формули, таблици, графики и други инструменти. Инфологичният модел отразява предметната област, за която е проектирана базата данни, и е напълно независим от физически параметрисреди за съхранение. Основните конструктивни елементи на инфологичните модели са същностите, връзките между тях и техните свойства (атрибути). Инфологичният модел не трябва да се променя, докато промените в реалния свят не водят до промени в предметната област и следователно промени в модела.
Описанието, създадено от разработчиците на база данни според инфологичния модел на данни, се нарича логически модел на данни. Крайният резултат от логическия дизайн е описанието логическа структурабази данни в DDL - езикът за описание на данни на конкретна СУБД. Когато се създава логически модел на данни, се осигурява съответствие едно към едно между конструкциите на езика за описание на данни и графични обозначенияинформационни единици и връзки между тях.
В основата на всяка СУБД е концепцията за модел на данни, тоест някаква абстракция на представяне на данни. Първоначално два конкурентни модела бяха успешни - йерархичен и мрежов. Йерархичната база данни се състои от подреден набор от дървета. IBM разработи и внедри езика за описание на данни DL/I (Data Language One), който моделира данните в йерархична форма (представяне на данни под формата на дървета). Този модел е разработен в сътрудничество с индустриални компании и е предназначен да съхранява и поддържа данни, които са йерархично свързани, като например сметки за материали и списъци с части. Типичен представител на йерархична СУБД е IMS СУБД (информация система за управление) от IBM, чиято първа версия се появи през 1968 г.
Фигура 8.1 показва пример за йерархична схема на база данни. Типът запис FACULTY е предшественик (родителски или родителски запис) на типовете записи DEPARTMENT и DECANATE, а типовете записи DEPARTMENT и DECANATE са наследници (записи на деца или деца) на FACULTY записа.
Всички случаи определен типна дъщерен запис, които принадлежат към същия екземпляр на родителския запис, се наричат близнаци. Йерархичният модел реализира връзка един към много между родителски и дъщерни записи, т.е. родителски записможе да съответства на произволен брой деца. В йерархичната база данни има единичен йерархичен път за достъп до всеки запис, започващ от корена на дървото, т.е. Редът на обхода на дървото е отгоре надолу, отляво-надясно. По същество йерархичният модел е насочен граф.
Ориз. 8.1.Схема йерархичен моделБаза данни
В терминологията на IMS вместо термина „запис“ се използва терминът „сегмент“, а терминът „запис на база данни“ се разбира като цялото дърво от сегменти. През 1970 г. групата CODASYL, която разработва стандарти за езика COBOL, създава модел, наречен DBTG (Data Base Task Group). Моделът DBTG беше готов да представи както йерархични, така и мрежови данни. Този модел обаче беше много сложен и следователно не особено успешен.
Типичен представител на системи, базирани на мрежов моделданните са IDMS СУБД (интегрирана Управление на база данни System), разработена от Cullinet Software, Inc. Мрежовият подход към организацията на данните е продължение на йерархичния подход. Както в йерархичния модел, връзките водят от родител към дете, но този път се поддържа множествено наследяване. В мрежовия модел са разрешени множество родителски записи за един дъщерен запис, заедно с възможността да има записи без родителски запис (Фигура 8.2). С други думи, в мрежовия модел всеки запис може да участва в няколко отношения родител-дете. Мрежовият модел е неориентиран граф.
Ориз. 8.2.Диаграма на мрежовия модел на базата данни
Повечето използвани днес бази данни се основават на релационния модел. Основната идея на релационния модел е да представи произволна структура от данни под формата на двуизмерни таблици. Най-разпространената настолна релационна база данни днес е MS Access, пример за която е разгледан в раздел 6.3.3.
Релационният модел е предложен за първи път от E.F. Код (E.F. Codd) през 1970г. Концепцията за модел на данни, въведена от Код, по-късно е разработена от Кристофър Дейт. Според Data, релационният модел се състои от три части, които описват различни аспекти на релационния подход: структурна част, манипулационна част и интегрална част. Данните се съхраняват в таблици. Колоните на таблицата се наричат полета, а редовете се наричат записи. Всяко поле може да съхранява само един вид информация. Заявките са предназначени да манипулират данните, съдържащи се в базата данни.
Код дефинира правилата на релационния модел, които се наричат "12-те правила на Код". По-късно Код добави "нулево" правило.
1. Релационна СУБДтрябва да може да управлява напълно базата данни, използвайки връзки между данните.
2. Правило за информация: Цялата информация в релационна база данни, включително имената на таблици и колони, трябва да се дефинира стриктно като стойности на таблицата.
3. Гарантиран достъп: Всяка стойност на базата данни трябва да бъде гарантирана, че е достъпна чрез комбинация от име на таблица, първичен ключ и име на колона.
4. Поддръжка на нулева стойност: СУБД трябва да може да работи с нулеви (празни) стойности. Нулева стойносте неизвестна, независима, неприложима стойност, за разлика от стойностите по подразбиране и редовни стойности.
5. Активен, онлайн релационен каталог - описанието на базата данни и нейното съдържание - трябва да бъде дефиниран на логическо ниво чрез таблици, които могат да бъдат запитани с помощта на DML (език за манипулиране на данни - език за манипулиране на данни).
6. Изчерпателно подмножество на езика на данните: от поне, един от поддържаните езици трябва да има добре дефиниран синтаксис и да бъде самостоятелен. Той трябва да поддържа дефиниране и манипулиране на данни, правила за интегритет, оторизация и транзакции.
7. Правило за актуализиране на изгледи: всички изгледи, които теоретично могат да се актуализират, могат да бъдат актуализирани чрез системата.
8. Вмъкване, актуализиране и изтриване: СУБД поддържа не само заявка за данни, но и вмъкване, актуализиране и изтриване.
9. Физическа независимостданни: логиката на приложните програми остава същата при промяна физически методиструктури за достъп и съхранение на данни.
10. Логическа независимост на данните: логиката на приложните програми остава същата, в рамките на разумното, при промяна на структурата на таблиците.
11. Независимост от целостта: Езикът на базата данни трябва да може да дефинира ограничения за целостта. Те трябва да са достъпни от онлайн директорията и не трябва да има начин да ги заобиколите.
12. Независимост на разпространението: прехвърлянето на база данни от един компютър на друг компютър не трябва да засяга заявките на приложните програми. Релационната СУБД не трябва да зависи от нуждите на конкретен клиент.
13. Езикова последователност на всички нива: Езикът за достъп до данни от ниско ниво не трябва да отменя правилата за сигурност и интегритет, поддържани от езика от по-високо ниво.
След като предложи модел на релационни данни, E.F. Код създава и инструмент за удобна работа с релации – релационна алгебра – формална система за манипулиране на отношенията, чиито основни операции са проекция, свързване, пресичане и обединение.
Релационното смятане е друга формална система, която манипулира отношенията. Релационното смятане се основава на логика от първи ред. Точно като изразите на релационната алгебра, формулите за релационно изчисление се дефинират върху релационни релации на база данни и резултатът от изчислението също е релация.
Релационната алгебра и релационното смятане имат еднаква изразителна сила; т.е. всички заявки, които могат да бъдат формулирани с помощта на релационна алгебра, могат също да бъдат формулирани с помощта на релационно смятане и обратно. Е. Ф. Код е първият, който доказва това през 1972 г. Това доказателство се основава на алгоритъм, чрез който произволно релационно изчисление може да бъде сведено до семантично еквивалентен израз на релационна алгебра. Алгоритъмът се нарича "алгоритъм за редукция на Код".
Релационните бази данни имат следните специфични характеристики.
· За всяко поле от таблицата на базата данни е дефиниран тип данни, така че не е възможно в едно поле различни записивъведете данни от различен тип.
· СУБД позволяват не само да се въвеждат данни в таблици, но и да се контролира коректността на въведените данни. Това се отнася не само до ограничения за типа данни, но и до контрола на валидни стойности, броя на въведените знаци и т.н. СУБД няма да позволи съхраняването в записа на тези данни, които не отговарят на посочените правила.
· Таблиците на базата данни могат да включват стотици хиляди записи, а СУБД предоставя удобни начини за извличане на желаната информация от тези много записи.
· Всички данни се съхраняват, независимо от тяхната структура и съдържание, в един файл, като достъпът до тези данни се осъществява страница по страница, без да се превишават ограниченията на компютърните ресурси.
· Можете да установите връзки между таблици и след това да използвате заявки за споделяне на данни от различни таблици. Данните, получени в резултат на заявката, също се представят под формата на таблица.
· Заявка за избор може да бъде приложена към една или повече таблици едновременно. Данните в извадката са динамични, т.е. кога рестартирамзапитване на променени данни, изборът се променя.
· Благодарение на установяването на връзки между отделните таблици е възможно да се избегне ненужното дублиране на данни, да се спести памет на компютъра и да се увеличи скоростта на обработка на информацията.
Повечето бази данни могат да поддържат едновременна работас база данни от няколко потребители, като се гарантира, че всички потребители работят с актуални данни.
· В сравнение с други пакети приложения, базите данни имат развита система за защита срещу неоторизиран достъп, която осигурява освен защита с паролафайл, възможността за всеки потребител или група потребители да вижда и променя само онези обекти, до които потребителите имат права за достъп.
При проектирането на релационна база данни се отделя голямо внимание на процеса на нормализиране на таблицата. Целта на нормализирането е да се създаде такъв проект за база данни, при който излишъкът на информация ще бъде изключен, т.е. всеки информационен квант ще се съхранява само на едно място. Основната цел на нормализирането е да се елиминират възможни несъответствия в съхраняваните данни и да се спести памет. Пренебрегването на нормализирането прави структурата на базата данни объркваща и самата база данни ненадеждна.
Теорията на нормализирането се основава на наличието на една или друга връзка между полетата на таблицата. Дефинирани са два вида такива зависимости: функционални и многозначни.
Поле B на таблица е функционално зависимо от поле A на същата таблица, ако и само ако в даден момент за всеки от различни значенияполе A задължително съществува само една от различните стойности на поле B. Имайте предвид, че тук е разрешено полетата A и B да могат да бъдат съставни.
Поле B е пълно функционална зависимоствърху съставно поле A, ако то функционално зависи от A и не зависи функционално от никое подмножество на полето A.
Поле A многозначно дефинира поле B от същата таблица, ако за всяка стойност на поле A има определен набор от съответстващи стойности B.
Процесът на нормализиране е последователна трансформация на изходната база данни в нормализирана база данни чрез постепенно привеждане на таблици в нормални форми (NF). В същото време всеки следващ НФ задължително включва предишния, което дава възможност процесът да се раздели на етапи и да се извърши веднъж, без да се връща към предишните етапи. Общо в релационна теорияИма 6 нормални форми: първа нормална форма (1NF), втора нормална форма (2NF), трета нормална форма (3NF), нормална форма на Бойс-Код (BCNF), четвърта нормална форма (4NF) и пета нормална форма (5NF) .
По същество една маса е във 2NF, ако е в 1NF и също така удовлетворява някои допълнителни условия. Една таблица е в 3NF, ако е във 2NF и освен това удовлетворява други допълнителни условия и т.н.
Таблицата е в първа нормална форма (1NF), ако и само ако нито един от нейните редове не съдържа повече от една стойност в което и да е от нейните полета и нито едно от ключовите й полета не е празно.
Таблицата е във втора нормална форма (2NF), ако удовлетворява дефиницията на 1NF и всички нейни полета, които не са първичен ключ, са напълно функционално зависими от първичния ключ.
Таблица е в трета нормална форма (3NF), ако удовлетворява дефиницията на 2NF и нито едно от нейните неключови полета не е функционално зависимо от други неключови полета.
Код и Бойс обосноваха и предложиха по-строга дефиниция за 3NF, която взема предвид, че може да има повече от един ключ в таблица. Таблицата е в нормална форма на Бойс-Код (BCNF), ако и само ако някоя функционална зависимост между нейните полета е напълно функционална, зависима от кандидат ключ.
Следните нормални форми (4NF и 5NF) вземат предвид не само функционалните, но и многозначните зависимости между полетата на таблицата.
В момента почти всеки производител на СУБД предлага собствен софтуерен продукт. компютърно подпомагано проектиране. Това са Oracle Designer (Oracle), Power Desinger (Sybase) и други. Демо версиитези софтуерни продукти могат да бъдат изтеглени от съответните уебсайтове (www.oracle.com, www.sybase.com). В допълнение, за компютърно проектиране са представени решения от фирми, които не произвеждат СУБД. Най-често срещаните са софтуерни продукти AllFusion - AllFusion ERwin данни Modeler и AllFusion Process Modeler (бивш BPwin) (вижте www.interface.ru).
Релационните езици осигуряват типични операции за обработка на релационни таблици, ви позволяват да формулирате логически условия, използвани в операциите за подбор, да проверявате целостта (последователността) на данните в свързани таблици. Те оперират с данни като с множества, прилагайки към тях основните операции на теорията на множествата. Входът на релационен оператор е набор от записи на една или повече релационни таблици, а изходът е набор от записи на нова релационна таблица. Релационните езици имат различно ниво на процедурност - съдържанието и последователността на прехода от вход към изход.
Различават се следните разновидности на езиците на релационна алгебра:
· Езиците, подобни на dBASe, са близки до езиците за структурирано програмиране. Тези езици осигуряват създаване на потребителски интерфейс и типични операции за обработка на данни;
Фокусирани върху графичните релационни езици крайни потребители;
· SQL-подобни езици за заявки, внедрени в повечето многопотребителски и разпределени системиуправление на база данни.
Езици, подобни на dBASe, използват бази данни dBASe, Paradox, FoxPro, Clipper, Rbase и др.
Типичен представител на графичен релационен език е езикът QBE (Query By Example), реализиран в среда на електронни таблици, в различни бази данни, например в MS Access, в пакета Microsoft Query. Този език принадлежи към езиците за манипулиране на данни и има най-простите синтактични конструкции, които лесно се овладяват от потребители, които не са програмисти.
SQL (Structured Query Language) се използва при работа с релационни бази данни в съвременните СУБД (ORACLE, dBASE IY, dBASE Y, Paradox, Access и др.). За отделните СУБД синтаксисът на версиите на SQL език може да се различава.
SQL се превърна в стандартен език за заявки за работа с релационни бази данни файл-сървър и клиент-сървър и за управление на разпределени бази данни. Това е релационно пълен език, предназначени за работа с бази данни, създаване на заявки за избор на данни, за извършване на изчисления, за осигуряване на целостта на базите данни.
База данни - организирана в съответствие с определени правила и поддържана в компютърната памет, набор от данни, които характеризират текущото състояние на определена предметна област и се използват за задоволяване информационни нуждипотребители.
Базата данни е колекция от данни, съхранявани в съответствие със схема на данни, която се манипулира в съответствие с правилата на инструментите за моделиране на данни.
Базата данни е колекция от свързани данни, съхранявани заедно в един или повече компютърни файлове.
Има много други определения, отразяващи по-скоро субективното мнение на определени автори за това какво означава този термин в тяхното разбиране, но няма общоприета единна формулировка. Най-често използваните отличителни характеристики са: Базата данни се съхранява и обработва в изчислителна система. По този начин всяко некомпютърно съхранение на информация (архиви, библиотеки, файлови шкафове и т.н.) не са бази данни.
Данните в базата данни са логически структурирани (систематизирани), за да се осигури възможността за тяхното ефективно търсене и обработка в компютърна система.
Структурирането предполага изричен подбор съставни части(елементи), връзки между тях, както и типизирането на елементи и връзки, в които определена семантика и разрешени операции са свързани с типа на елемент (връзка).
От изброените характеристики само първата е строга, докато други позволяват различни интерпретации и различна степен на оценка. Можете да установите само известна степен на съответствие с изискванията за базата данни.
Много експерти посочват често срещана грешка, състояща се в неправилна употребатермина база данни вместо термина система за управление на база данни. Следователно тези понятия трябва да бъдат разграничени.
Базите данни са необходими за съхраняване и филтриране на информация, за нейната обработка и обмен. Като цяло обхватът на приложение е доста широк. По целия свят хората използват базата данни, вариращи от обикновен потребител любител до най-големите световни корпорации.
Базата данни е хранилище за Голям бройсистематизирани данни, с които можете да извършвате определени действия. Действията означават добавяне, изтриване, промяна, копиране, подреждане и т.н.
Всички данни в базата данни могат да бъдат представени като записи или обекти.
За успешна работас база данни са необходими някои софтуерни инструменти, с които човек може да създава и управлява база данни. За да направите това, съществуват системи за управление на бази данни (СУБД).
СУБД - набор от език и софтуерни инструменти, осигуряващи създаването, използването и поддръжката на базата данни.
Има два вида СУБД: локални и мрежови.
Local - СУБД, работеща на един компютър. Те включват dBase, FoxPro, Microsoft Access, Paradox и др.
Мрежови са СУБД, които позволяват на множество компютри да използват една и съща база данни, използвайки технология клиент-сървър. Примери за такива СУБД са InterBase, Oracle, Microsoft SQL сървъри т.н. Тъй като анализираме общи понятия, тогава ще говоря малко за връзката на данните.
Има 4 вида връзка с данни:
1) Едно към едно
2) Един към много
3) Много към едно
4) Много към много
Връзката едно към едно означава, че всеки запис на един обект на база данни ще сочи към един запис на друг обект.
Един към много означава, че един запис на обект от база данни ще съответства на няколко записа на други обекти.
Много към едно означава, че няколко записа на обекти от база данни ще съответстват на един запис на друг обект.
Много към много се задава между два типа обекти на базата данни.
Характеристики на базата данни
Базата данни е компютърно внедрена информационна структура (модел), която отразява състоянието на обектите и техните взаимоотношения.
Трябва да се отбележи, че това определение не е единственото възможно. По отношение на дефинициите информатиката най-често не прилича на математиката с пълната си недвусмисленост. Ако подходим към концепцията за „база данни“ от чисто персонализирана точкаизглед, тогава възниква друго определение: базата данни е набор от съхранени оперативни данни на предприятието. Всичко е за това кой аспект доминира в разглеждането; в тази глава първото от дефинициите е по-подходящо.
Опитът от използване на бази данни прави възможно подчертаването общ комплекттехните експлоатационни характеристики:
* пълнота - колкото по-пълна е базата данни, толкова по-вероятно е тя да съдържа необходимата информация(все пак не трябва да има излишна информация);
* правилна организация- колкото по-добре е структурирана базата данни, толкова по-лесно е да се намери необходимата информация в нея;
* уместност – всяка база данни може да бъде точна и пълна, ако се актуализира постоянно, т.е. необходимо е базата данни във всеки момент от време да съответства напълно на състоянието на показвания от нея обект;
* лекота на използване - базата данни трябва да е проста и лесна за използване и да има усъвършенствани методи за достъп до всяка част от информацията.
Според възможностите за организиране на релационни, йерархични и мрежови информационни структури съществуват подобни типове бази данни.
Основни видове бази данни
1) Йерархичен
2) Мрежа
3) Релационни
Йерархични бази данни
Йерархичните бази данни са използвани в началото на 60-те години. Те са построени под формата на обикновено дърво. Данните са разделени на 2 категории: главен и подчинен. Така един тип обект е основен, а останалите, разположени на по-ниските нива на йерархията, са подчинени.Бази данни, организирани по този принцип, са удобни за използване в случаите, когато информацията е подредена съответно.
Мрежови бази данни
Мрежовите бази данни започнаха да се използват почти едновременно с йерархичните. В тези бази данни всеки обект може да бъде както главен, така и подчинен.
При употреба е доста трудно да се приложи представяне на данни в тази форма, така че този тип също беше изоставен.
Релационни бази данни
Релационни бази данни се използват в Ежедневието. (от англ. relation - връзка). Този тип база данни е представена от няколко свързани помежду си правоъгълни таблици. В които има собствени полета, ключове, записи, атрибути и така нататък и така нататък.
