Цели и задачи проектирования

Цели и задачи проектирования. Основная цель процесса проектирования БД состоит в получении такого проекта, который удовлетворяет следующим требованиям корректности схемы БД, т. е. база данных должна быть гомоморфным образом моделируемой предметной области, где каждому объекту предметной области соответствуют данные в памяти ЭВМ, а каждому процессу предметной области - адекватные процедуры обработки данных. При этом результаты выполнения процесса и соответствующих ему процедур обработки данных должны совпадать в любой момент функционирования, если это предусмотрено проектом обеспечение ограничений на конфигурацию вычислительной системы, в первую очередь, на ресурсы внешней и оперативной памяти эффективность функционирования, т. е. Обеспечение требований ко времени реакции системы на запросы и обновления БД защита данных от разрушений при сбоях оборудования от некорректных обновлений и, если необходимо, от несанкционированного доступа. простота и удобство эксплуатации информационной системы гибкость, т. е. возможность развития и последующей адаптации системы к изменениям в предметной области и к новым потребностям пользователей.

Удовлетворение первых четырех требований обязательно для принятия проекта.

Последние два требования необязательны, так как большая или меньшая простота и удобство эксплуатации выступают только факторами оценки альтернативных вариантов проекта. СТРУКТУРА ПРОЦЕССА ПРОЕКТИРОВАНИЯ Обследование предметной области.

На этом этапе рис.1, после первоначального знакомства с предметной областью следует детальное изучение всех ее фрагментов, каждый из которых характеризуется локальным пользовательским представлением. Для каждого фрагмента определяются информационные объекты, анализируются процессы, их использующие, и устанавливаются явные ассоциации между информационными объектами. Фрагменты предметной области исследуются последовательно.

Причем сведения об очередном фрагменте интегрируются с полученными при изучении предшествующих фрагментов. Выбор СУБД. Система управления БД важнейший программный компонент информационной системы, оказывающий существенное влияние на многие параметры системы, в том числе пользовательские интерфейсы эффективность функционирования стоимость разработки приложений стоимость эксплуатации гибкость системы. ОБСЛЕДОВАНИЕ ПРЕДМЕТНОЙ ОБЛАСТИ ВЫБОР СУБД ПРОЕКТЕРОВАНИЕ РЕАЛИЗАЦИИ Рис. 1. Структура процесса проектирования Предлагаемая методика выбора СУБД позволяет последовательно выявить внешние ограничения, выделить СУБД-претенденты на использование, провести моделирование базы данных для каждой выделенной СУБД и сравнительный анализ полученных моделей базы данных. Выявление внешних ограничений.

Под внешними ограничениями здесь понимаются ограничения среды реализации информационной системы.

Каждая среда реализации отлична от идеальной. Она содержит множество ограничений, среди которых наиболее важные для нас технические, программные и организационные. Технические ограничения определяются конфигурацией вычислительной системы, параметрами функционирования е компонентов, наджностью их работы и др. Программные ограничения в первую очередь подразумевают операционную систему и языки прикладного программирования.

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

На выбор СУБД-претендентов наибольшее влияние оказывает согласование ряда параметров среды реализации и СУБД. К таким параметрам в первую очередь относятся тип ЭВМ операционная система объемы оперативной памяти конфигурация вычислительной системы и наличие реализаций СУБД для нескольких типов ЭВМ. Моделирование базы данных. Для каждой из выделенных СУБД моделируется база данных.

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

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

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

Для каждого фактора рекомендуется определить количественную оценку. Например, для фактора возможность совмещения разработки с ранее выполненными программными реализациями в роли количественной оценки могут выступить трудозатраты на создание соответствующих программных интерфейсов или стоимость повторных программных реализаций. Проектирование реализации. Последний, третий этап проектирования состоит из двух шагов конструирования схемы базы данных, а также разработка программного обеспечения и технологии ведения информационной системы. Конструирование схемы БД. На этом шаге проектирования окончательно уточняются все параметры логической и физической организации БД. Разработка технологии ведения ИС. Разрабатывается набор технологических инструкций для службы администратора БД. Эти инструкции охватывают все процессы, выполняемые на стадиях реализации и эксплуатации информационной системы.

В первую очередь это ввод информации в систему защита данных управление использованием данных управление эффективностью системы.

Программное обеспечение технологии ведения ИС составляют сервисные средства, необходимые для выполнения большинства процессов, включенных в технологию. Это могут быть стандартные программные продукты из состава СУБД или независимо поставляемые либо оригинальные программные разработки. Определяя программное обеспечение, оговаривается его состав, а для оригинальных программ разрабатываются их алгоритмы.

ТЕХНОЛОГИЯ ВЕДЕНИЯ ИНФОРМАЦИОННОЙ СИСТЕМЫ Ввод информации, в систему. Информация, хранимая и используемая в системе, включает в себя нормативно-справочные сведения большинства приложений, а также сведения, поступающие в систему при выполнении приложений, в том числе и в реальном масштабе времени. Последний, вид информации характеризуется более коротким сроком существования, чем нормативно справочная информация. В информационной системе для учебного заведения как и в нашем случае к нормативно-справочным относятся сведения о преподавателях, учебных планах, студентах а ко второй разновидности сведения о расписании, посещаемости занятий, об аттестации студентов.

Очевидно, если состав преподавателей, списки студентов и учебные планы в течение года не меняются, то информация второй разновидности корректируется ежедневно. Е загрузка и корректировка осуществляются конечными пользователями при выполнении функциональных приложений. Защита данных.

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

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

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

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

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

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