Процедурний
Непроцедурний
Основна різниця між ними в тому, що процедурні мови вказують те, як можна отримати результати оператора мови DML, тоді як непроцудурні мови описують те, який результат буде отриманий. В процедурних мовах записи розгладаються окремо, а непроцедурні - з цілими наборами записів.
Процедурна мова DML - дозволяє повідомити системі про те, які дані необхідні, і точно вказати, як їх можна вилучити. За допомогою процедурної DML програміст вказує які дані йому потрібні і як їх можна отримати. Така мова дозволяє вилучити запис, обобити його, і в залежності від отриманих результатів, вилучити інший запис, який обраблюється так само.
Непроцедурна мова DML – дозволя вказати лише те, які дані потрібні, але не те, як їх потрібно вилучити.
Процедурна мова DML дозволяє визначити вес набір потребних даних з адопомогою одного оператору вилучення або обновлення. СУБД транслює вирази на мові DML в процедуру, яка забезпечує маніпулювання отриманим набором записів.
Процедурні мови часто наз декларативными языками.
Частина Процедурної мови DML, яка відповідає з авилучення даних наз мовою запитів.
Мава 4GL – мова четвертого покоління. Мова йде про деякий стенографическом варіанті мови програмування. Мава 4GL - не процедурна, оскільки користувачі визначають, що повинно бути зроблено, а не про те як потрібний результат повинен буде отриманий.
Типи мов четвертого покоління:
мови придставлення інформації, наприклад мови запитів або генератори звітів;
спеціалізовані мови – мови електроних таблиць і БД;
генератори додатків, які при створенні додатку забезпечують визначення, втавку, обновлення або вилучення сведений з БД;
мови дуже високого рівня, презначені для генерації код додатків.
13_ Архітектура клієнт-сервер. Розподілена обробка. Архитектура многопользовательских субд
В данном разделе рассмотрим кратко различные типовые архитектурные решения, используемые при реализации многопользовательских СУБД, а именно: с телеобработкой, файл-серверными и клиент-серверными системами.
Телеобработка. Традиционной архитектурой многопользовательских систем раньше считалась схема, получившая название "телеобработки", при которой один компьютер был соединен с несколькими "неинтеллектуальными" терминалами так, как показано на рис. 5.2. С терминалов посылались сообщения пользовательским приложениям, в свою очередь, приложения обращались к необходимым службам СУБД. Таким же образом сообщения возвращались назад на пользовательский терминал. При такой архитектуре вся нагрузка возлагалась на центральный компьютер, который должен был выполнять не только действия прикладных программ и СУБД, но и значительную работу по обслуживанию терминалов (например, форматирование данных, выводимых на экраны терминалов).
В настоящее время в связи с развитием информационно-вычислительных сетей получили широкое распространение файл-серверные и клиент-серверные СУБД.
Рис.
5.2 Топология архитектуры телеобработки
Файл - серверные системы. Системы данного типа функционируют в рамках локальных вычислительных сетей (ЛВС), управляемых ОС соответствующего типа. При этом файловый сервер содержит файлы, необходимые для работы приложений и самой СУБД. Однако пользовательские приложения и сама СУБД размещены и функционируют на отдельных рабочих станциях, и обращаются к файловому серверу только по мере необходимости получения доступа к нужным им файлами - как показано на рис. 5.3. Таким образом, файловый сервер функционирует просто как совместно используемый жесткий диск.
Рис.
5.3 Архитектура с использованием файлового
сервера
Очевидно, что архитектура с использованием файлового сервера обладает следующими основными недостатками:
- Большой объем сетевого трафика. - На каждой рабочей станции должна находиться полная копия СУБД. - Управление параллельностью, восстановлением и целостностью усложняется, поскольку доступ к одним и тем же файлам могут осуществлять сразу несколько экземпляров СУБД.
Клиент-серверные системы. При данном подходе предполагается существование клиентского процесса, требующего определенных ресурсов, а также серверного процесса, который эти ресурсы предоставляет. При этом совсем необязательно, чтобы они находились на одном и том же компьютере. На практике системы данного типа реализуются в рамках информационно-вычислительных сетей (не обязательно ЛВС) под управлением клиент-серверных ОС (см. рис. 5.4).
В контексте базы данных клиентская часть управляет пользовательским интерфейсом и логикой приложения, действуя как интеллектуальная рабочая станция, на которой выполняются приложения баз данных. Клиент принимает от пользователя запрос, проверяет синтаксис и генерирует запрос к базе данных на SQL или другом языке БД, который соответствует логике приложения. Затем он передает сообщение серверу, ожидает поступления ответа и форматирует полученные данные для представления их пользователю. Сервер принимает и обрабатывает запросы к базе данных, а затем передает полученные результаты обратно клиенту. Такая обработка включает проверку полномочий клиента, обеспечение требований целостности, поддержку системного каталога, а также выполнение запроса и обновление данных. По-мимо этого, поддерживается управление параллельностью и восстановлением. Выполняемые клиентом и сервером операции приведены ниже.
Рис.
5.4 Общая схема построения систем с
архитектурой "клиент/сервер"
Клиент:
- Управляет пользовательским интерфейсом; - Принимает и проверяет синтаксис введенного пользователем запроса; - Выполняет приложение; - Генерирует запрос к базе данных и передает его серверу; - Отображает полученные данные пользователю.
Сервер:
- Принимает и обрабатывает запросы к базе данных со стороны клиентов; - Проверяет полномочия пользователей; - Гарантирует соблюдение ограничений целостности; - Выполняет запросы/обновления и возвращает результаты клиенту; - Поддерживает системный каталог; - Обеспечивает параллельный доступ к базе данных; - Обеспечивает управление восстановлением.
Этот тип архитектуры обладает приведенными ниже преимуществами.
- Обеспечивается более широкий доступ к существующим базам данных. - Повышается общая производительность системы. Поскольку клиенты и сервер находятся на разных компьютерах, их процессоры способны выполнять приложения параллельно. - Стоимость аппаратного обеспечения снижается. Достаточно мощный компьютер с большим устройством хранения нужен только серверу - для хранения и управления базой данных. - Сокращаются коммуникационные расходы. Приложения выполняют часть операций на клиентских компьютерах и посылают через сеть только запросы к базе данных, что позволяет существенно сократить объем пересылаемых по сети данных. - Повышается уровень непротиворечивости данных. Сервер может самостоятельно управлять проверкой целостности данных, поскольку все ограничения определяются и проверяются только в одном месте. - Эта архитектура хорошо согласуется с архитектурой открытых систем. - Данная архитектура может быть использована для организации средств работы с распределенными базами данных, т.е. с набором нескольких баз данных, логически связанных и распределенных в компьютерной сети.
Необходимо заметить, что в настоящее время данная архитектура рассматривается обычно в трехуровневом варианте, при котором функциональная часть прежнего, толстого (интеллектуального) клиента разделяется на две части. В трехуровневой архитектуре тонкий (неинтеллектуальный) клиент на рабочей станции управляет только пользовательским интерфейсом, тогда как средний уровень обработки данных управляет всей остальной логикой приложения. Третьим уровнем здесь является сepвep базы данных. Эта трехуровневая архитектура оказалась более подходящей для некоторых сред - например, для сетей Internet и intranet, где в качестве клиента может использоваться обычный Web-броузер.
Архітектура клієнт-сервер є одною з найпопулярніших концепцій при створенні інформаційних систем. В цій архітектурі передбачені наступні компоненти:
серверна частина (збереження і обробка інформації)
клієнтська частина (робочий інструмент користувача)
мережа, яка забезпечує взаємодію (обмін інформацією) між клієнтом і сервером
Саме на цій архітектурі і базуються більшість веб-орієнтованих систем. Як типовий приклад архітектури клієнт-сервер розглянемо наступну схему: Приклад системи електронної комерції створений на основі архітектури "клієнт-сервер". Компанія що займається торгівлею має електронний магазин, що продає різні види продукції, простий сайт з загальною інформацією про компанію та інтранет-систему для забезпечення фінансового обліку діяльності компанії. В середині компанії працівники використовуючи в ролі клієнтської звичайний веб-браузер опрацьовують і зберігають усі процеси діяльності підприємства. Дані зберігаються на сервері, що містить наступні елементи:
систему управління базами даних (СУБД)
програмні модулі, що забезпечують функціонування бізнес-логіки
Розглянемо як в цій системі буде виглядати облік руху товарної продукції від моменту обліку його на складі і до моменту його продажу і відвантаження:
працівник вводить свої персональні авторизаційні дані в спеціальну форму авторизації, що сформована сервером і завантажена в веб-браузер
бізнес-логіка сервера обробляє ці дані звіряючи їх з збереженими в СУБД
якщо авторизаційні дані введені коректно, сервер формує інтерфейс користувача і відправляє його в веб-браузер
працівник викликає інтерфейс обліку прихідної накладної і вносить товар
сервер отримавши дані по приходу товару обробляє їх, автоматично формує ціни реалізації згідно заздалегідь запрограмованих умов, зберігає в СУБД кінцевий результат обробки
автоматизований програмний модуль публікує дані про прийнятий на склад товар за допомогою синхронізації на сервер, що обслуговує електронний магазин, і одночасно здійснює прийом інформації про проданий товар
для покупців і партнерів, що підписані на отримання оперативної інформації про товар система формує лист і відсилає за допомогою електронної пошти
звичайний покупець завантаживши веб-сторінку компанії і побачивши новину про прихід товару в магазині, що також автоматично сформована системою, чи дізнавшись про прихід товару за допомогою електронної пошти завантажує сторінку електронного магазину компанії
авторизувавшись в системі покупець переглядає новий товар і здіснює покупку
сервер електронного магазину обробляє отримані від покупця дані і зберігає їх в СУБД, відсилає необхідні повідомлення через електронну пошту
при наступній синхронізації дані про покупку отримуються на внутрішній сервер компанії і представляються до обробки працівникам
працівники оформляють на основі отриманих даних накладну (якщо звичайно покупець розрахувався через інтернет при формування замовлення в електронному магазині), дають вказівку відвантажити товар покупцю
Це лише загальний опис функціонування системи на базі “клієнт-сервер”. Такі системи можуть бути надзвичайно різноманітними і розгалуженими. Переваги веб-орієнтованих систем базованих на клієнт-серверній архітектурі:
мінімум затрат на обслуговування бізнес-процесів
максимальна оперативність при оперуванні даними
зручність в обслуговуванні, більшість операцій може виконуватись автоматично
один працівник може легко обслуговувати кілька процесів одночасно без особливих зусиль
мінімум затрат на комунікації між підрозділами компанії
оперативне і гнучке отримання звітів про діяльність компанії
веб-сервер, СУБД і програмні модулі що забезпечують функціонування бізнес-логіки як правило розміщуються на одному комп’ютері
працівникові для роботи з системою потрібний лише звичайний веб-браузер
роботу з системою можна здійснювати з будь якого комп'ютера що приєднаний до інтернету