Бази данни - анализ


Категория на документа: Информатика


• извличане на данни, съдържащи се в базата данни;
• Изтриване на данни от базата данни.

Procedural DML Език, който позволява на потребителя да каже на системата какви данни са необходими и как точно да обработи данните.

Non-procedural DML е език, който дава възможност на приложния програмист да посочи какви данни са необходими, вместо как те да се получат!

Fourth-Generation Languages (4GLs)
Няма консенсус по въпроса какво точно представлява fourth-generation language; това по същество е стенограмата език за програмиране. Операция, която изисква стотици редове на език от трето поколение (3GL), като например COBOL, обикновено изисква значително по-малко редове в 4GL. В сравнение с 3GL, който е Процедурно ориентиран, 4GL не е: потребителят дефинира какво трябва да се направи, а не как. 4GL разчитат до голяма степен на готови компоненти от много по-високо ниво, известни като 4-то поколение инструменти. Потребителят не определят стъпките, които една програма трябва да изпълни за решаване на задачата, а вместо това определя параметри за инструментите, които ги използват за генериране на програма. Твърди се, че 4GLs може да подобри производителността на приложния програмист десет пъти, с цената на ограничаване на видовете задачи, които могат да се решават. Fourthgeneration езици включват: презентационни езици, заявки, доклад, инсърти, ъпдейти, делийти (SQL, QBE).

Application generators Генератори на приложения Аpplication generator е програма, която създава програма за взаимодействие с базата данни. Използването на генератори на приложения намяляват времето за програмна реализация на една информационна система. Application generators типично използват предварително написани (програмирани) модули, които чрез параметри се настройв ат към конкретната схема на базата данни и реализират фундаментални функции на информационната система ( CRUD = create, read, update and delete). , Тези модули обикновено са написани на езици от високо ниво high-level language и представляват библиотеки от функции. Потребителят (приложният програмист) специфицира какво трябва да прави модулът, a генераторът определя как да се изпълни задачата

2 Компоненти на СУБД
СУБД е разделена на няколко софтуерни компоненти (модули), на всеки от които е възложена конкретна операция. Някои от функциите на СУБД се поддържат от основната операционна система. Обаче, операционната система предоставя само основните услуги и СУБД трябва да бъде изградени върху това. По този начин, при проектирането на СУБД трябва да се вземе предвид интерфейса между СУБД и операционната система. Основните компоненти софтуер в СУБД са представени на фигура 2.8.
Тази диаграма показва как СУБД взаимодействията с други софтуерни компоненти, като например потребителски заявки и методи за достъп (модулни техники на управление за съхраняване и извличане на записани данни). .
Фигура 2.8 съдържа следните съставни части:
* Процесор на заявки - Това е важен компонент от СУБД , който трансформира заявките в серия от инструкции в по-долно ниво насочени към модул за управление на базата данни. .
* Модул за управление на базата дани- Модулът за управление на базата дани приема заявки взаимодейства с потребителско- подадените заявления програми и заявки. DM приема заявки и разглежда външни и концептуални схеми, за да се определи какви концептуални записи са необходими за удовлетворяване на искането. DM после се обръща към файловия мениджър да изпълни заявката. Компонентите на DM са показани на фигура 2.9.
* • Модул за управление на файловете - Модулът за управление на файловете ръководи основните файлове за съхранение и управлява разпределението на пространството за съхранение в диска. Той създава и поддържа списък на структурите и индексите, определени във вътрешния схема.

• Език за обработка на данните (data manipulation language, DML)Този модул преобразува DML отчетите, вградени в приложна програма, в стандартна функция изискваща хост език. DML трябва да си взаимодейства със заявителния процесор за да генерира съответния код.
• Език за дефиниране на данни (data definition language, DDL) -DDL превръща DDL отчетите в набор от таблици, съдържащи метаданни. Тези таблици се съхраняват в системния каталог докато контролната информация се съхрани в заглавията на файловете с данни.
• Catalog manager - Управлява достъпа до и поддържа системния каталог.Системния каталог е достъпен за повечето компоненти на СУБД.
Основните компоненти на модула за управление на базата данни са както следва:
• Authorization control- Този модул проверява дали потребителят има необходимото разрешение за извършване на необходимата операция.
• Command processor- Веднъж след като системата е проверила, че потребителят има право да извърши операцията, управлението се предава на командния процесор.
• Integrity checker -За операция, която променя базата данни, Integrity checker проверява дали исканата операция отговаря на всички необходими ограничения за интегритет (като основните пречки).
• Query optimizer- Този модул определя оптимална стратегия за изпълнение на заявката. Ще разгледаме Query optimizer в глава 21.
• Модул на транзакциите- Този модул извършва необходимата обработка на операции получени от транзакциите.
• Изпълнител на задачи Този модул трябва да гарантирането, че едновременни операции в базата данни няма да влизат в конфликт една с друга. Тя контролира относителния ред, в който транзакционните операции се извършват.
• Възстановителен модул- Този модул гарантира, че базата данни остава по едно резервно състоянието, в случай на авария. Той е отговорен за сделката-да я приемем или да откажем.
• Буфер мениджър Този модул е ​​отговорен за прехвърлянето на данни между главната памет и второто хранилище, като например диск и касета. Recovery manager и мениджър буфер понякога се наричат ​​общо модул за управляване на данни. Буфер мениджър е известно като модул за управление на кеш паметта.

Мулти - потребителски СУБД архитектури
В този раздел ще се спрем на по основните архитектури, които се използват за изпълнение на мулти-потребителско управление на бази данни системи, а именно телеобработка, файлов сървър и клиент-сървър.
Телеобработка Традиционната архитектура за мулти-потребителските системи е била телеобработката, при която имаме компютър с една централна оперираща единица (CPU) и още няколко терминалаЦелият процес се извършва само от един компютър. Потребителските терминали са обикновено"dumb" и не умеят да функционират сами. Те са свързани с главния компютър. Терминалите изпращат съобщения, чрез комуникационно-контролната подсистема на операционната система, на приложната програма на потребителя, която от своя страна използва услугите на СУБД.

Файл- сървър - архитектура
Във файл-сървър средата обработката се разпределя между мрежата, обикновено локална мража (LAN). Файл-сървърът държи файловете изисквани от приложението и СУБД. Въпреки това приложенията и СУБД работят на всяка работна станция, изисквайки файлове от файл-сървъра когато е необходимо. По този начин, файл-сървърът действа просто като споделен твърд диск.

Figure 2.11 File-server architecture
Файл- сървър архитектурата има три основни недостатъка:
1) Създава се голямо количество мрежови трафик.
2) Пълно копие на СУБД е необходимо на всяка работна станция.
3) Съгласуваност, възстановяване и цялостният контрол са по-сложни, тъй като може да има множество СУБД имащи достъп до едни и същи файлове.

Традиционна двуслойна клиент-сървър архитектура

Това е клиент процес, който изисква някъкви ресурси и сървър, който осигурява ресурсът. Не се изисква клиентът и сървърът да се намират на една и съща машина. На практика е нормално да се поставя сървърът на едно място в локалната мрежа и клиентите в други сайтове. Data-intensive бизнес приложенията съдържат четири основни компонента: базите данни, логиката на транзакцията, бизнес и логика на приложението данни и потребителски интерфейс. Традиционната двуслойна клиент-сървър архитектура осигурява много добро разделяне на тези компоненти. Клиентът (слой 1) носи отговорност основно за представянето на данните на потребителя,а сървърът (слой 2)- предоставяне на данни на клиента. Има много предимства на този тип архитектура. Например: по-широк достъп, по-голяма производителност, по-малки разходи, по-голяма съгласуваност, съдържа отворени архитектури.

Клиент



Сподели линка с приятел:





Яндекс.Метрика
Бази данни - анализ 9 out of 10 based on 2 ratings. 2 user reviews.