Решения, принятые на предыдущем уровне, при разработке модели предметной области, определяют некоторые границы, в пределах которых можно развивать логическую модель данных, в пределах же этих границ можно принимать различные решения. Например, модель предметной области складского учета содержит понятия "склад", "накладная", "товар". При разработке соответствующей реляционной модели эти термины обязательно должны быть использованы, но различных способов реализации тут много – можно создать одно отношение, в котором будут присутствовать в качестве атрибутов "склад", "накладная", "товар", а можно создать три отдельных отношения, по одному на каждое понятие.
При разработке логической модели данных возникают вопросы: хорошо ли спроектированы отношения? Правильно ли они отражают модель предметной области, а следовательно и саму предметную область?
Для того чтобы оценить качество принимаемых решений на уровне логической модели данных, необходимо сформулировать некоторые критерии качества в терминах физической модели и конкретной реализации и посмотреть, как различные решения, принятые в процессе логического моделирования, влияют на качество физической модели и на скорость работы базы данных.
Таких критериев может быть очень много и выбор их произволен. Некоторые из таких критериев являются важными с точки зрения получения качественной базы данных: адекватность базы данных предметной области, легкость разработки и сопровождения базы данных, скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей), скорость выполнения операций выборки данных.
База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия.
1. Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.
2. Изменение состояния предметной области должно приводить к соответствующему изменению состояния базы данных.
3. Ограничения предметной области, отраженные в модели предметной области, должны некоторым образом отражаться и учитываться базе данных.
Практически любая база данных, за исключением совершенно элементарных, содержит некоторое количество программного кода в виде триггеров и хранимых процедур.
Хранимые процедуры – это процедуры и функции, хранящиеся непосредственно в базе данных в откомпилированном виде и которые могут запускаться пользователями или приложениями, работающими с базой данных. Основное назначение хранимых процедур –реализация бизнес-процессов предметной области.
Триггеры – это хранимые процедуры, связанные с некоторыми событиями, происходящими во время работы базы данных. В качестве таких событий выступают операции вставки, обновления и удаления строк таблиц. Если в базе данных определен некоторый триггер, то он запускается автоматически всегда при возникновении события, с которым этот триггер связан. Триггер срабатывает независимо от того, кто из пользователей и каким способом инициировал событие, вызвавшее запуск триггера. Таким образом, основное назначение триггеров – автоматическая поддержка целостности базы данных.
Очевидно, что чем больше программного кода в виде триггеров и хранимых процедур содержит база данных, тем сложнее ее разработка и дальнейшее сопровождение.
На уровне логического моделирования определяются реляционные отношения и атрибуты этих отношений. На этом уровне можно определять какие-либо физические структуры хранения (индексы, хеширование и т.п.). Единственное, чем можно управлять – это распределение атрибутов по различным отношениям. Можно описать немного отношений с большим количеством атрибутов, или сформировать большое количество отношений, каждое из которых содержит мало атрибутов. Таким образом, необходимо попытаться ответить на вопрос – влияет ли количество отношений и количество атрибутов в отношениях на скорость выполнения операций обновления данных. Такая постановка не является достаточно корректной, т.к. скорость выполнения операций с базой данных зависит от физической реализации базы данных. Тем не менее, целесообразно качественно оценить это влияние при одинаковых подходах к физическому моделированию.
Основными операциями, изменяющими состояние базы данных, являются операции вставки, обновления и удаления записей. В базах данных, требующих постоянных изменений (складской учет, системы продаж билетов и т.п.) производительность определяется скоростью выполнения большого количества небольших операций вставки, обновления и удаления.
Обычно, вставка записи производится в одну из свободных страниц памяти, выделенной для данной таблицы. СУБД постоянно хранит информацию о наличии и расположении свободных страниц. Если для таблицы не созданы индексы, то операция вставки выполняется фактически с одинаковой скоростью независимо от размера таблицы и от количества атрибутов в таблице. Если в таблице имеются индексы, то при выполнении операции вставки записи индексы должны быть перестроены. Таким образом, скорость выполнения операции вставки уменьшается при увеличении количества индексов у таблицы и мало зависит от числа строк в таблице.
Для операции обновления и удаления записей из таблицы, прежде, чем обновить или удалить запись, ее необходимо найти. Если таблица не индексирована, то единственным способом поиска является последовательное сканирование таблицы в поиске нужной записи. В этом случае, скорость операций обновления и удаления существенно увеличивается с увеличением количества записей в таблице и не зависит от количества атрибутов. Но на самом деле неиндексированные таблицы практически никогда не используются. Для каждой таблицы обычно объявляется один или несколько индексов, соответствующий потенциальным ключам. При помощи этих индексов поиск записи производится очень быстро и практически не зависит от количества строк и атрибутов в таблице (хотя, конечно, некоторая зависимость имеется). Если для таблицы объявлено несколько индексов, то при выполнении операций обновления и удаления эти индексы должны быть перестроены, на что тратится дополнительное время. Таким образом, скорость выполнения операций обновления и удаления также уменьшается при увеличении количества индексов у таблицы и мало зависит от числа строк в таблице.
Одно из назначений базы данных – предоставление информации пользователям. Информация извлекается из реляционной базы данных при помощи оператора SQL –SELECT. Одной из наиболее дорогостоящих операций при выполнении оператора SELECT является операция соединение таблиц. Таким образом, чем больше взаимосвязанных отношений было создано в ходе логического моделирования, тем больше вероятность того, что при выполнении запросов эти отношения будут соединяться, и, следовательно, тем медленнее будут выполняться запросы. Таким образом, увеличение количества отношений приводит к замедлению выполнения операций выборки данных, особенно, если запросы заранее неизвестны.
6. РАСПЕРДЕЛЕННАЯ ОБРАБОТКА ДАННЫХ [6] глава 1,2, [7] раздел 2.2.
Распределенная обработка данных – методика выполнения прикладных программ группой систем.
Сущность ее заключается в том, что пользователь получает возможность работать с сетевыми службами и прикладными процессами, расположенными в нескольких взаимосвязанных абонентских системах. При этом возможны несколько видов работ, которые он может выполнять: удаленный запрос, например, команда, позволяющая посылать одиночную заявку на выполнение обработки данных; удаленная трансакция, осуществляющая направление группы запросов прикладному процессу; распределенная трансакция, дающая возможность использования нескольких серверов и прикладных процессов, выполняемых в группе абонентских систем.
Для распределенной обработки осуществляется сегментация прикладных программ. Передача данных происходит при помощи удаленного вызова процедур либо электронной почты. Первая технология характеризуется высоким быстродействием, а вторая – низкой стоимостью. Известны также программные средства Системы Управления Распределенной Базой Данных (СУРБД), содержатся инструментальные средства распределенной среды обработки данных.
Распределенная среда обработки данных – представляет собой технологию распределенной обработки данных.
Эта среда обычно - набор сетевых служб, предназначенный для выполнения прикладных процессов, рассредоточенных по группе абонентских систем гетерогенной сети. Основные ее компоненты показаны в табл. 1.
Табл 1. Основные компоненты распределенной обработки данных.
| № п/п | Служба | Выполняемые функции |
| 1. | Имена | База Данных имен пользователей и средств, предназначенных для доступа пользователей к сетевым службам. |
| 2. | Удаленный доступ | Технология, обеспечивающая взаимодействие двух прикладных программ, расположенных в различных абонентских системах. |
| 3. | Защита данных | Программное Обеспечение разрешения на доступ к ресурсам системы или сети. |
| 4. | Многопоточностъ | Программы, обеспечивающие одновременное выполнение нескольких задач. |
Системы, имеющие программы распределенной среды, соответственно, являются серверами и клиентами. Серверы связаны (рис. 1) друг с другом логическими каналами, по которым передают друг другу файлы. Каждый сервер имеет свою группу клиентов.