Модель сервера приложений (as)
Модель сервера приложений (AS) - представляет собой процесс, выполняемый на компьютере-клиенте, отвечающий за интерфейс с пользователем (т.е. реализует функции первой группы).
Прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (Application Server - AS).
Доступ к информационным ресурсам осуществляет менеджер ресурсов (например, SQL-сервер). Из прикладных компонентов доступны такие ресурсы как, базы данных, очереди, почтовые службы и др. AS, размещенная на компьютере, где функционирует менеджер ресурсов, избавляет от необходимости направления SQL-запросов по сети, что повышает производительность системы.
Модели RDA и DBS опираются на двухзвенную схему разделения функций:
- в RDA-модели прикладные функции отданы программе-клиенту (прикладной компонент сливается с компонентом представления);
- в DBS-модели ответственность за их выполнение берет на себя ядро СУБД (прикладной компонент интегрируется в компонент доступа к информационным ресурсам).
В AS-модели реализована трехзвенная схема разделения функций. Здесь прикладной компонент выделен как важнейший изолированный элемент приложения. Сравнивая модели, AS обладает наибольшей гибкостью и имеет универсальный характер.
Разработка структуры бд.
Системы хранения и обработки данных являются основой большинства организационных и многих технических ИС. Задача систем хранения и обработки данных – эффективное, безопасное и удобное хранение данных и работа с ними в многопользовательском режиме.
БД является хранилищем структурированных данных. При этом данные должны быть минимально избыточными и целостными.
Существует несколько моделей баз данных – иерархическая, сетевая и реляционная. Реляционная модель данных является самой популярной и предполагает, что все данные представляются в виде таблиц. В этом случае принято строки называть записями, а столбцы таблицы – полями. Каждая таблица – набор записей с одинаковой структурой.
Первичный ключ. В каждой таблице должен быть определен первичный ключ. Это поле или группа полей, однозначно идентифицирующих запись. Значение ПК должно быть уникально, то есть не должно быть нескольких записей с одинаковым значением ПК. Обычно при разработке БД в качестве ПК выбирают поля, имеющие смысловое значение в предметной области. Если среди полей нет пригодных на роль ПК, то вводят семантически незначащие ключи (коды, идентификационные номера и так далее). ПК отчеркивается в таблице горизонтальной линией (в Access так же).
Связи (реляционные отношения) между таблицами БД. Между двумя таблицами БД могут существовать отношения подчиненности. Отношения определяют, что для записи одной таблицы могут существовать записи другой таблицы. В общем случае выделяют 3 типа связей: 1 к 1, 1 ко многим, многие ко многим. Единственной связью между таблицами БД, которая выражается в явном виде, задается и поддерживается СУБД, является связь “1 ко многим”. Она обозначается так:
Точка ставится со стороны многого. Со стороны “1” связь подходит к ПК, так как от него зависят все остальные данные, содержащиеся в таблице.
Если между таблицами отношение “1 к 1”, то они объединяются в одну таблицу. Если между таблицами отношение “многое ко многому”, то такая связь выражается с помощью вспомогательных таблиц и отношения “1 ко многому”.
Внешний ключ. Поле Товар таблицы “Продажа” является полем связи между таблицами “Товар” и “Продажа”, в этом поле содержится название товара, который продали. То есть по названию можно узнать всю дополнительную информацию о проданном товаре. Другими словами, поле Товар является ссылкой на ПК таблицы товар. Такие поля называют внешними ключами. Лучше, чтобы ПК и ВК были одноименны.