Модель сервера баз данных (DBS)

 

Модель сервера баз данных (DBS) - реализована в некоторых реляционных СУБД (Informix, Ingres, Sybase, Oracle), (рис.4.9).

Ее основу составляет механизм хранимых процедур - средство программирования SQL-сервера. Процедуры хранятся в словаре баз данных, разделяются между несколькими клиентами и выполняются на том же компьютере, где функционирует SQL-сервер. В DBS-модели компонент представления выполняется на компьютере-клиенте, в то время как, прикладной компонент оформлен как набор хранимых процедур и функционирует на компьютере-сервере БД. Там же выполняется компонент доступа к данным, т.е. ядро СУБД.

Понятие информационного ресурса сужено до баз данных, поскольку механизм хранимых процедур - отличительная характеристика DBS-модели - имеется пока только в СУБД.

 

 

Достоинства DBS-модели:

- возможность централизованного администрирования прикладных функций;

- снижение трафика (вместо SQL-запросов по сети направляются вызовы хранимых процедур);

- возможность разделения процедуры между несколькими приложениями;

- экономия ресурсов компьютера за счет использования единожды созданного плана выполнения процедуры. К недостаткам относится:

- ограниченность средств написания хранимых процедур, представляющих собой разнообразные процедурные расширения SQL, которые уступают по изобразительным средствам и функциональным возможностям в сравнении с языками С или Pascal. Сфера их использована ограничена конкретной СУБД из-за отсутствия возможности отладки и тестирования разнообразных хранимых процедур.

На практике чаще используются смешанные модели, когда целостность базы данных и некоторые простейшие прикладные функции обеспечиваются хранимыми процедурами (DBS-модель), а более сложные функции реализуются непосредственно в прикладной программе, которая выполняется на компьютере-клиенте (RDA-модель).

 

Модель сервера приложений (AS)

 

Модель сервера приложений (AS) - представляет собой процесс, выполняемый на компьютере-клиенте, отвечающий за интерфейс с пользователем (т.е. реализует функции первой группы).

Прикладной компонент реализован как группа процессов, выполняющих прикладные функции, и называется сервером приложения (Application Server - AS).

Доступ к информационным ресурсам осуществляет менеджер ресурсов (например, SQL-сервер). Из прикладных компонентов доступны такие ресурсы как, базы данных, очереди, почтовые службы и др. AS, размещенная на компьютере, где функционирует менеджер ресурсов, избавляет от необходимости направления SQL-запросов по сети, что повышает производительность системы.

Модели RDA и DBS опираются на двухзвенную схему разделения функций:

- в RDA-модели прикладные функции отданы программе-клиенту (прикладной компонент сливается с компонентом представления);

- в DBS-модели ответственность за их выполнение берет на себя ядро СУБД (прикладной компонент интегрируется в компонент доступа к информационным ресурсам).

В AS-модели реализована трехзвенная схема разделения функций. Здесь прикладной компонент выделен как важнейший изолированный элемент приложения. Сравнивая модели, AS обладает наибольшей гибкостью и имеет универсальный характер.

 

Разработка структуры БД.

 

Системы хранения и обработки данных являются основой большинства организационных и многих технических ИС. Задача систем хранения и обработки данных – эффективное, безопасное и удобное хранение данных и работа с ними в многопользовательском режиме.

БД является хранилищем структурированных данных. При этом данные должны быть минимально избыточными и целостными.

Существует несколько моделей баз данных – иерархическая, сетевая и реляционная. Реляционная модель данных является самой популярной и предполагает, что все данные представляются в виде таблиц. В этом случае принято строки называть записями, а столбцы таблицы – полями. Каждая таблица – набор записей с одинаковой структурой.

 

Первичный ключ. В каждой таблице должен быть определен первичный ключ. Это поле или группа полей, однозначно идентифицирующих запись. Значение ПК должно быть уникально, то есть не должно быть нескольких записей с одинаковым значением ПК. Обычно при разработке БД в качестве ПК выбирают поля, имеющие смысловое значение в предметной области. Если среди полей нет пригодных на роль ПК, то вводят семантически незначащие ключи (коды, идентификационные номера и так далее). ПК отчеркивается в таблице горизонтальной линией (в Access так же).

Связи (реляционные отношения) между таблицами БД. Между двумя таблицами БД могут существовать отношения подчиненности. Отношения определяют, что для записи одной таблицы могут существовать записи другой таблицы. В общем случае выделяют 3 типа связей: 1 к 1, 1 ко многим, многие ко многим. Единственной связью между таблицами БД, которая выражается в явном виде, задается и поддерживается СУБД, является связь “1 ко многим”. Она обозначается так:

 

 

Точка ставится со стороны многого. Со стороны “1” связь подходит к ПК, так как от него зависят все остальные данные, содержащиеся в таблице.

Если между таблицами отношение “1 к 1”, то они объединяются в одну таблицу. Если между таблицами отношение “многое ко многому”, то такая связь выражается с помощью вспомогательных таблиц и отношения “1 ко многому”.

 

Внешний ключ. Поле Товар таблицы “Продажа” является полем связи между таблицами “Товар” и “Продажа”, в этом поле содержится название товара, который продали. То есть по названию можно узнать всю дополнительную информацию о проданном товаре. Другими словами, поле Товар является ссылкой на ПК таблицы товар. Такие поля называют внешними ключами. Лучше, чтобы ПК и ВК были одноименны.

 

Порядок разработки структуры БД:

 

1 этап – Уточнение задачи, формирование требований к работе системы. Как минимум, необходимо дать четкие ответы на следующие вопросы:

1. назначение БД (как, кем, для каких целей будет использоваться БД);

2. требования к информации БД (подробно, четко и понятно описать, как информация должна храниться в БД);

3. требования к функциям (указать все функции БД).

2 этап – Необходимо в явном виде выделить основные сущности, представить их в виде схемы и дать текстовые пояснения.

Цель этапа – представить всю информацию в виде относительно независимых наборов атрибутов, которые и называются сущностями, и которые соответствуют объектам и явлениям предметной области.

3 этап – Нормализация.

4 этап – Проектирование таблиц.

 

Аномалии в таблицах

 

Табельный номер	Фамилия	Специальность	Почасовая ставка	Вид объекта	Дата
	Архипов	Электрик		Дом	01.10
	Архипов	Электрик		Дет Сад	02.10
	Шаров	маляр		Дом	01.10
	Шаров	маляр		Офис	04.10
	Шаров	маляр		Бассейн	03.10
	Шаров	маляр		Дет Сад	02.10
	Земин	электрик		Бассейн	01.10

 

Такая база спроектирована неудачно. Много избыточности, которые приводят к аномалиям (противоречиям).

Аномалия обновления – противоречивость данных обусловленная их избыточностью и частичным обновлением. (Предположим, что маляру повысили ставку со 120 до 125 рублей, а исправления вошли только в 1 строку, получается противоречие - это называется аномалией обновления).

Аномалия удаления – непреднамеренная потеря данных, вызванная удалением других данных. (При завершении работ на одном объекте (например басен), все записи связанные с этим объектом удаляются, при этом теряется информация о Земине - Это аномалия удаления).

Аномалия ввода – невозможность ввести данные в таблицу, вызванные отсутствием других данных. (При приеме на работу сотрудника, который еще не назначен на объект не может быть внесён в эту таблицу, т.к. вид объекта должен быть заполнен, получается, что нового работника нет в штате – это аномалия добавления)

Аномалии всегда нежелательны. Чтобы предотвратить их используется нормализация таблиц (разделение на более мелкие таблицы с помощью применения нормальных форм).

Нормальная форма – это набор правил, которым должна удовлетворять структура таблицы

Нормализация

Нормализация – это процесс преобразования структуры Базы Данных, цель которого исключение избыточности данных.

Это ключевой этап разработки структуры, заключающийся в приведении структуры БД к так называемой третьей нормальной форме (3 НФ).