На этапе предварительного обследования объекта автоматизации используется компонента Designer - средство построения диаграмм деловых процессов BPR. С его помощью можно не только построить модель всех процессов, протекающих в ходе повседневной деятельности, но и провести ряд анализов, способных выявить узкие места.

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

Процесс создания модели предполагает коллективную работу над проектом. Существуют мощные средства организации такой работы, разделения модели на части для независимой разработки и "сшивания" частей модели в целое.

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

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

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

а) Oracle Developer;

б) Oracle Power Objects;

в) Oracle WebServer;

г) MS Visual Basic 3.0 и 4.0;

д) Классы C/C+;

е) Oracle JDeveloper.

Этот список постоянно пополняется новыми продуктами.

Важным моментом работы системы является возможность восстановить модель приложения по уже существующему приложению, созданного без применения Designer, с помощью процедуры реинжиниринга. Даже вручную сделанные изменения, в сгенерированной системе, можно отразить в модели приложения. Это гарантирует, что при последующей генерации кода они не будут потеряны.

В настоящий момент корпорация Oracle предлагает множество решений, с применением различных продуктов. Каждый продукт имеет свои плюсы и минусы, но самым «большим минусом» цена конечного продукта Oracle. Поэтому, для снижения первоначальных затрат, целесообразно использовать программные пакеты иных производителей, что будет на порядок дешевле. В этом случае возможно применение нескольких пакетов для охвата всего спектра работ. Главное требование к используемым пакетам - совместимость решений.

1.6 Постановка задачи на проектирование

база данные проектирование информационный

Интенсификация процессов, в различных областях деятельности, требует внедрения новых подходов и технологий при решении традиционных задач. Если в начале 80-х годов двадцатого века было приемлемо затрачивать на разработку нового изделия до 10 лет, то в 90-х годах сроки разработки проекта сократились до трех лет. Ускорение процессов произошло не за счет использования экстенсивного подхода, а путем применения интенсивных методик разработки. Интенсивные методы разработки подразумевают использование разнообразных систем автоматизации. Очевидно, что наиболее эффективные системы автоматизации имеют механизм, который объединяет многих разработчиков в единый коллектив, на основе использования самой системы автоматизации работ. В этом случае система автоматизации должна обеспечивать своих пользователей возможностью хранения, как индивидуальных результатов труда, так и механизмом который объединяет выполненные работы в один проект. Основой такого механизма может быть система хранения и сбора информации, которая интегрирует необходимую для выполнения работ информацию.

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

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

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

2. Обоснование выбора операционной системы и системы управления базой данных среды реализации проекта

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

При анализе систем с высокой производительностью следует обратить внимание на то, что наиболее высокие показатели надежности и производительности получены на вычислительных платформах, где функционирует ОС UNIX [10]. Из всех клонов ОС UNIX выделяется платформа фирмы Sun Microsystems, с ОС Solaris. Это обусловлено тем, что за последние насколько лет фирма Sun Microsystem активно развивала операционную систему (версии ОС Solaris - 8, 9, 10), Java технологии и технические средства - создание ряда процессоров и на их основе исполнение целого ряда рабочих станции и серверов различного назначения. Компания проводила широкую маркетинговую политику, что вылилось в значительном снижении стоимости технических средств и программного обеспечения. На сегодня компания Sun Microsystems может предложить широкий выбор рабочих станций и масштабируемых серверов, способных удовлетворить потребности любого пользователя.

Приведем пример характеристик локального сервера Sun Microsystems на конец двадцатого века. Например, сервер SPARCserver 1000/1000E может использоваться в качестве многоцелевого сервера NFS или сервера небольшого предприятия, поддерживающего работу до 1500 пользователей. SPARCserver 1000/1000E имеет модульную конструкцию, в которую могут устанавливаться до 8 процессоров 50, 60 или 75 МГц SuperSPARC с кэшем второго уровня емкостью 1 Мб на каждый процессор. Шина XDbus, работающая в режиме пакетного переключения, обеспечивает модульное расширение количества процессоров, карт ввода/вывода, оперативной памяти и другое. В системном блоке могут устанавливаться до четырех плат (системных или дисковых). На каждой системной плате могут размещаться один или два процессорных модуля, работающих на частоте 50, 60 или 75 МГц и до 512 Мб оперативной памяти. Каждая системная плата содержит 3 слота расширения, два последовательных порта, контроллер SCSI-2 и контроллер сети Ethernet. Таким образом, максимальный объем оперативной памяти системы может достигать 2 Гб, а количество S-bus слотов - 12. Свободные слоты S-bus могут использоваться для установки карт видеоадаптеров, сетевых контроллеров и дополнительных контроллеров SCSI-2. Максимальный объем дискового пространства может достигать 760 Гб.

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

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

- гибкость конструктивных решений, обеспечивающая простую и удобную линию наращивания производительности путем увеличения количества процессоров, объемов оперативной памяти, емкости дисков, количества и типов сетевых адаптеров;

- двоичная совместимость, начиная с простых настольных систем и кончая высокопроизводительными центрами обработки данных, дающую возможность легко разрабатывать и переносить прикладные программы с системы на систему без дополнительных затрат;

- гибкие средства управления системой, упрощающие управление сложными сетями, включающими сети Novell NetWare, Banyan VINES или AppleTalk;

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

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

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

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

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



Размещено на http://www.allbest.ru/

Рисунок 2.1 - Традиционная организация распределенной базы данных

Если говорить об информационных технологиях то следует отметить, что предложенная конфигурация позволяет создавать аппаратно независимые системы. Применительно к этому можно сказать, что, универсальным называется решение, которое не зависит от:

- языка программирования:

- аппаратной платформы;

- операционной системы;

- конкретного сетевого протокола;

- любых двоичных стандартов и структур.

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

Использование ОС UNIX позволит всех пользователей системы разбить на группы, для которых прописываются правила доступа к ресурсам и разрабатывается соответствующий интерфейс пользователя, необходимый для исполнения функциональных задач специалиста. Жесткой привязки специалиста к рабочему месту (ПЭВМ) можно избежать, в случае разработки открытой системы или наоборот - зафиксировать рабочее место, инициировав контроль за всеми параметрами подключения пользователя к системе, для систем у которых имеется секретная информация или реализована защита информации от несанкционированного доступа. Последний режим работы лучше всего реализовывать в корпоративной сети, где ограничены выходы в Internet.

В системе проектирования, под защитой информации понимается комплекс мероприятий состоящий из:

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

- подсистемы управления защитой данных основанной на разделении источников информации на санкционированные и несанкционированные области. Для некоторых пользователей доступ к любому источнику сети является несоответствующим его статусу;

- организации парольного доступа к техническим средствам и создание схем доступа пользователей к базе данных проекта.

Если с ОС вычислительной платформы все очевидно, то при выборе СУБД могут возникнуть споры. Следует помнить:

- что более восьмидесяти процентов корпоративных баз данных реализовано на СУБД Oracle;

- все решения в рамках СУБД Oracle аппаратно независимы;

- СУБД Oracle поддерживает связи по SQL запросу с двадцатью различными СУБД;

- СУБД Oracle работает со всеми сетевыми протоколами;

- СУБД Oracle имеет самую высокую производительность при обработке запросов;

- СУБД Oracle обладает самым мощным встроенным инструментарием разработчика.

Краткий перечень возможностей СУБД Oracle должен убедить разработчика в том, что использование этого продукта в проекте наиболее целесообразно, так как другие СУБД такого класса (Informix, DB2) отстают по интегрированным показателям.

В случае выбора вышеперечисленных платформ возможно построение масштабируемой системы проектирования. Первые этапы работ над проектом можно выполнять и на иных платформах, позаботившись только о соблюдении основных концепций. Это обеспечит перенос разработки с платформы, например, Windows/Oracle на платформу Solaris/Oracle без дополнительной доработки, за исключением модификации путей поиска в скрипт-файлах.

3. Разработка базы данных и описание программной реализации

3.1 Роль CASE-средств при проектировании информационной модели

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

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

Методология объектно-ориентированного анализа различает и рассматривает три вида связей:

- один к одному;

- один ко многим;

- многие ко многим;

Это объясняется различными подходами и методами их реализации в отдельных компьютерных технологиях. Так, связи один к одному реализуется преимущественно матрицами, связи один ко многим на базе реляционной алгебры и реляционных таблиц, а связи “многие ко многим” требуют использования вспомогательного объекта.

Кроме того, в методологии ООА принят графический вид информационных моделей, как предварительных, базисных для последующего моделирования состояний - жизненных циклов. В информационной модели каждому объекту должно быть назначено уникальное имя. При этом имя должно явно указывать отношение объекта или к классу объектов или к экземпляру[6].

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

- неадекватная спецификация требований;

- неспособность обнаруживать ошибки в проектных решениях;

- низкое качество документации, снижающее эксплуатационные качества;

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

Перечисленные факторы способствовали появлению программно-технологических средств специального класса - CASE-средств, реализующих CASE-технологию создания и сопровождения ИС. Термин CASE (Computer Aided Software Engineering) используется в настоящее время в весьма широком смысле. Первоначальное значение термина CASE, ограниченное вопросами автоматизации разработки только лишь программного обеспечения (ПО), в настоящее время приобрело новый смысл, охватывающий процесс разработки сложных ИС в целом. Теперь под термином CASE-средства понимаются программные средства, поддерживающие процессы создания и сопровождения ИС, включая анализ и формулировку требований, проектирование прикладного ПО и баз данных, генерацию кода, тестирование, документирование, обеспечение качества, конфигурационное управление и управление проектом, а также другие процессы. CASE-средства вместе с системным ПО и техническими средствами образуют полную среду разработки ИС.

CASE-технология представляет собой методологию проектирования ИС, а также набор инструментальных средств, позволяющих в наглядной форме моделировать предметную область, анализировать эту модель на всех этапах разработки и сопровождения ИС и разрабатывать приложения в соответствии с информационными потребностями пользователей. Большинство существующих CASE-средств основано на методологиях структурного (в основном) или объектно-ориентированного анализа и проектирования, использующих спецификации в виде диаграмм или текстов для описания внешних требований, связей между моделями системы, динамики поведения системы и архитектуры программных средств[6].

3.2 Разработка структуры хранилища данных

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

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

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

Распределенные СУБД могут содержать несколько десятков и сотен серверов БД. Количество клиентских мест в них может достигать десятков и сотен тысяч. Интерес к распределенным СУБД возрос в связи с о стремительным развитием Интернета[10].

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

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

3.3 Нормализация отношений

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

Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ).

Этот процесс включает:

- устранение повторяющихся групп (приведение к 1НФ);

- удаление частично зависимых атрибутов (приведение к 2НФ);

- удаление транзитивно зависимых атрибутов (приведение к 3НФ).

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

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

Переход от ненормализованных отношений к отношениям в 3НФ может быть выполнен при помощи алгоритма нормализации. Данный алгоритм заключается в последовательной декомпозиции отношений для устранения функциональных зависимостей атрибутов от части составного ключа (приведение к 2НФ) и устранения функциональных зависимостей неключевых атрибутов друг от друга (приведение к 3НФ).

Отношение R находится в 3НФ тогда и только тогда, когда отношение находится во 2НФ и все неключевые атрибуты взаимно независимы.

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

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

Данный этап был проведен при построении инфологической модели данных с использованием языка ER-диаграмм.

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

Исходное отношение: R(К1, К2, А1, …, Аn , В1, … ,Вm).

Ключ: (К1, К2) - составной.

Функциональные зависимости: (К1, К2) ? (А1, …, Аn , В1, … ,Вm).

(К1) ? (А1, …, Аn) - зависимость некоторых атрибутов от части составного ключа.

Декомпозированные отношения:

R1(К1, К2, В1, … ,Вm) - остаток от исходно отношения. Ключ (К1, К2).

R2(К1, А1, …, Аn) - атрибуты, вынесенные из исходного отношения вместе с частью составного ключа . Ключ (К1).

При приведении к 3НФ, анализируются отношения с точки зрения наличия зависимости неключевых атрибутов от других неключевых атрибутов. Если такие зависимости обнаружены, то проводим декомпозицию следующим образом: те неключевые атрибуты, которые зависят от других неключевых атрибутов выносятся в отдельное отношение. В новом отношении ключом становится детерминант функциональной зависимости:

Исходное отношение: R(К, А1, …, Аn , В1, … ,Вm).

Ключ: (К).

Функциональные зависимости: К ? (А1, …, Аn , В1, … ,Вm) - зависимость всех атрибутов от ключа.

(А1, …, Аn) ? (В1, … ,Вm) - зависимость некоторых неключевых атрибутов от других неключевых атрибутов.

Декомпозированные отношения:

R1(К, А1, …, Аn) - остаток от исходно отношения. Ключ К.

R2(А1, …, Аn, В1, … ,Вm)) - атрибуты, вынесенные из исходного отношения вместе с детерминантом функциональной зависимости. Ключ (А1, …, Аn).

Последовательно выполнив данный алгоритм, получаем базу данных, приведенную к 3НФ и содержащую упорядоченную информацию, детально отображающую рассматриваемую предметную область. После проведения нормализации таблиц, с целью устранения избыточного дублирования данных и группирования информации в логически связанных единицах, отметим, что разбиение информации на более мелкие логические единицы, с одной стороны, способствует повышению надежности и непротиворечивости данных, а с другой стороны, снижает ее производительность, так как требуются дополнительные затраты процессорного времени на обратное соединение таблиц при предоставлении информации пользователю[8].

3.4 Логическая модель БД

Применив средства ERwin выполним преобразование модели логической структуры базы данных в физическую модель структуры, смотри рис.3.4. При выполнении преобразования были определены типы и размеры элементов хранимых таблиц. На основании созданной модели физической структуру базы данных выполним генерацию скрипт-файла создания элементов БД, который приведен в приложении А, или выполним генерацию хранимых элементов в базе данных. Из исходного текста скрипт-файла, имеем возможность сформировать два файла - файл генерации модулей в базе данных и файл удаления модулей из базы данных. Это позволяет более оперативно манипулировать структурами хранения в базы данных в случае их модификации, так как оба файла легко редактируются. Для выполнения удаления или генерации новой структуры таблиц базы данных достаточно выполнить команду SQL*PLAS

start <имя диска>:\<полный путь к файлу>\<имя скрипт-файла>.sql;

Следующим технологическим действием будет быстрая генерация, средствами Oracle Developer, пользовательского интерфейса и его проверка на работоспособность, смотри рис3.5.

3.5 Проектирование хранимых процедур и представлений

Получив положительный отзыв от прикладных специалистов о том, что интерфейсы, которые разработанные средствами Oracle Developer, соответствуют требованиям и полностью удовлетворяют разработчиков, необходимо приступать к созданию хранимых процедур и представлений [12-15]. Это необходимо выполнить, так как предполагается, что создаваемая система будет обслуживать большое число рабочих мест. Следовательно, разрабатывается большое количество приложений. Такая ситуация опасна тем, что при отсутствии ограничений доступа к базе данных, разработчики приложений могут пополнять БД новыми хранимыми модулями, что обязательно будет вызывать конфликты среди разработчиков из-за отсутствия достоверной документации. Кроме этого, эффективно администрировать такую базу данных невозможно, что неизбежно приведет к развалу системы.

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

Создадим представление, при помощи которого можно просмотреть список хранимых компонент проектирования:

Пример разрабатываемого представления

CREATE VIEW Component_view

AS SELECT

ID_COMP, ID_COMP_R, NAME_KOMP, DATE_R_KOMP

FROM Component;

Такое представление можно усложнить, за счет использования условий поиска или объединения нескольких таблиц. Решение на создание новых представлений будут приниматься по мере развития системы.

Следующим видом хранимых модулей будет процедура. В настоящее время под хранимой процедурой понимается как процедура PL/SQL так и Java-скрипт. Рассмотрим пример традиционной процедуры на рис. 3.6, которая позволит получить информацию о назначении компоненты.

Пример хранимой процедуры

create or replace procedure COMP_SEL_ DESC(

ID_COMP in number,

ID_COMP_R in number,

NAME_KOMP out varchar2(250),

DATE_R_KOMP out date,

APP_KOMP out varchar2(250),

NAMB_INPUT out number,

NAMB_OUTPUT out number) as

begin

SELECT

ID_COMP, ID_COMP_R, NAME_KOMP, DATE_R_KOMP,

APP_KOMP, NAMB_INPUT, NAMB_OUTPUT

FROM COMPONENT, DESC_COMP

WHERE

COMPONENT.ID_COMP = DESC_COMP.ID_COMP

AND

COMPONENT.ID_COMP_R = DESC_COMP.ID_COMP_R

end COMP_SEL_DESC;

Создание хранимых модулей базы данных будет выполняться по мере решения теоретических и практических задач. Заранее спланировать список хранимых модулей не представляется возможным.

4. Описание системы защиты информации

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

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

Вся работа по обеспечению безопасности связи в каналах телекоммуникации должна начинаться с организационных мер защиты:

- установление персональной ответственности за обеспечение защиты информации;

- ограничение доступа в помещения, где происходит подготовка и обработка информации;

- доступ к обработке, хранению и передаче информации только проверенных должностных лиц;

- постоянный контроль устройств вывода ценной информации на материальный носитель.

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

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

- иметь длину не менее семи символов;

- содержать символы каждой из трех следующих групп: буквы прописные и строчные (A, B, C,...; a, b, c,...), цифры (0, 1, 2, 3, 4, 5, 6, 7, 8, 9), символы, не относящиеся ни к буквам, ни к цифрам (` ~ ! @ # $ % ^ & * ( ) + - = { } | [ ] \ : " ; ' < > ? , . /);

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

- существенно отличаться от предыдущих паролей;

- не содержать личного имени или имени пользователя;

- не являться распространенным словом или именем.

Выделение некоторых прав доступа к ресурсам система осуществляется посредством использования ролей. Так, в системе присутствует три роли: администратор, сотрудник и начальник. Только администратор может создавать структуру организации путем создания отделов, пользователей и выделять пользователям некоторые права. Сотрудник работает с документом, который «пришел» в его отдел. Роль начальник расширяет права сотрудника и добавляет пользователю с такой ролью некоторую дополнительную функциональность и обязывает его выполнять некоторые дополнительные действия (утверждение документа на определенном этапе, например).

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

Выводы

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

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

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

В итоге был получен результат, на который можно опереться при дальнейшей разработке системы.

Перечень ссылок

1. Гради Буч Объектно-ориентированное проектирование с примерами применения

2. Э.Гамма, Р.Хелм, Р.Джонсон, Д.Влиссидес Приемы объектно-ориентированного проектирования Паттерны проектирования - СПб. ПИТЕР, 2006 - 306с.

3. Острейковский В. А. Теория систем. М: Высшая школа, 1997.

4. Д. Росс Структурный анализ (SA): язык для передачи понимания // Требования и спецификации в разработке программ. М.: Мир, 1984.

5. D. A. Marka, McGovan К. L. SADT: Structured Analysis and Design Technique. N. Y.: McGraw Hill, 1988.

6. И.В. Галахов, Д.В. Лапыгин, А.Н. Новичков, О.Р. Подоляк, Б.А Позин Автоматизированное создание документов серии ГОСТ 34 и 19 с помощью инструментальных средств фирмы IBM Rational Доклад и статья опубликованы в рамках III-ей Всероссийской практической конференции: "Стандарты в проектах современных информационных систем" www.osp.ru, www.fostas.ru

7. Георгий Калянов - Публикации. Калянов Г.Н. CASE - технологии проектирования программного обеспечения // Кибернетика и системный анализ,...... и основные направления их развития // Материалы семинара "CASE технология", М.: ЦРДЗ,... - http://kalyanov.by.ru/publications/index.htm

8. CASE-технологии: Практикум : Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. : 05.02.2005 - 15 Kb - http://www.bookler.ru/bookisbn/5-93517-121-x.shtml

9. Бизнес-моделирование (обзор методов) . http://en.wikipedia.org/wiki/Business_process

10. Д.В. Богданов, В.А. Путилов, В.В. Фильчаков Стандартизация процессов обеспечения качества программного обеспечения. - Апатиты, КФ ПетрГУ, 1997. - 16

11. В.Н.Касьянов, В.А.Евстигнеев Графы в программировании: обработка, визуализация и применение - СПб. БХВ Питербург, 2003 - 1104 с.

12. Питер Колетски, д-р Поль Дорси Oracle Designer Настольная книга пользователя Издательство ЛОРИ, 1999

13. Серверы корпоративных баз данных http://www.sitforum.ru

14. С.В.Маклаков EPwin и BRwin CASE-средства разработки информационных систем, Москва, ДИАЛОГМИФИ, 2000

15. Л. Сорокин Средства разработки Oracle как инструменты инженерного подхода в создании промышленного программного обеспечения, Oracle

16. Кевин Луни, Марлен Терью Oracle 9i Настольная книга администратора Перевод с англ., Москва, изд. ЛОРИ, 2004 - 748 с.

17. С.В. Глушаков, Ю.В. Третьяков, О.А. Головаш Администрирование Oracle 9i Харьков, ФОЛИО, 2003 -695 с.

18. С. Фейершттейн, Б. Прибыл Oracle PL/SQL для профессионалов СПб.: Питер, 2003. -941 с.

19. К. Дж. Дейт. Введение в системы баз данных. 6-е издание. Издательский дом «Вильямс», 2000 - 848 с

Приложение

Cкрипт создания/удаления хранимых модулей базы данных

DROP TABLE Connect_In_Comp CASCADE CONSTRAINTS;

CREATE TABLE Connect_In_Comp (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

ID_Connect NUMBER NOT NULL,

Type_Connect NUMBER NOT NULL,

Sourse_ID_Comp NUMBER NULL,

Sourse_ID_Comp_R NUMBER NULL,

Sourse_Exit_ID_Output NUMBER NULL,

Rec_ID_Comp NUMBER NULL,

Rec_ID_Comp_R NUMBER NULL,

Rec_Entr_ID_Input NUMBER NULL

);

DROP INDEX XPKConnect_In_Comp;

DROP INDEX XIF14Connect_In_Comp;

CREATE UNIQUE INDEX XPKConnect_In_Comp ON Connect_In_Comp

(

ID_Comp ,

ID_Comp_R ,

ID_Connect

);

CREATE INDEX XIF14Connect_In_Comp ON Connect_In_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Desc_Comp CASCADE CONSTRAINTS;

CREATE TABLE Desc_Comp (

ID_Comp_R NUMBER NOT NULL,

ID_Comp NUMBER NOT NULL,

App_Komp VARCHAR2(250) NOT NULL,

Namb_INPUT NUMBER NOT NULL,

Namb_OUTPUT NUMBER NOT NULL

);

DROP INDEX XPKDesc_Comp;

CREATE UNIQUE INDEX XPKDesc_Comp ON Desc_Comp

(

ID_Comp_R ,

ID_Comp

);

DROP TABLE Graph_Prod CASCADE CONSTRAINTS;

CREATE TABLE Graph_Prod (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

ID_Lang_C NUMBER NULL,

Lang_C VARCHAR2(250) NOT NULL

);

DROP INDEX XPKGraph_Prod;

DROP INDEX XIF11Graph_Prod;

CREATE UNIQUE INDEX XPKGraph_Prod ON Graph_Prod

(

ID_Comp ,

ID_Comp_R ,

ID_Lang_C

);

CREATE INDEX XIF11Graph_Prod ON Graph_Prod

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Test_Comp CASCADE CONSTRAINTS;

CREATE TABLE Test_Comp (

ID_Comp_R NUMBER NOT NULL,

ID_Comp NUMBER NOT NULL,

Kind_Test NUMBER NOT NULL,

Code_Test CLOB NOT NULL

);

DROP INDEX XPKTest_Comp;

DROP INDEX XIF12Test_Comp;

CREATE UNIQUE INDEX XPKTest_Comp ON Test_Comp

(

ID_Comp_R ,

ID_Comp ,

Kind_Test

);

CREATE INDEX XIF12Test_Comp ON Test_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Realiz_Comp CASCADE CONSTRAINTS;

CREATE TABLE Realiz_Comp (

ID_Comp_R NUMBER NOT NULL,

ID_Comp NUMBER NOT NULL,

Kind_realiz NUMBER NOT NULL,

Cod_realiz CLOB NOT NULL

);

DROP INDEX XPKRealiz_Comp;

DROP INDEX XIF11Realiz_Comp;

CREATE UNIQUE INDEX XPKRealiz_Comp ON Realiz_Comp

(

ID_Comp_R ,

ID_Comp ,

Kind_realiz

);

CREATE INDEX XIF11Realiz_Comp ON Realiz_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Prom_Mod_Repl_Comp CASCADE CONSTRAINTS;

CREATE TABLE Prom_Mod_Repl_Comp (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

Lang_mod NUMBER NOT NULL,

Cod_Model_Repl CLOB NOT NULL

);

DROP INDEX XPKProm_Mod_Repl_Comp;

DROP INDEX XIF9Prom_Mod_Repl_Comp;

CREATE UNIQUE INDEX XPKProm_Mod_Repl_Comp ON Prom_Mod_Repl_Comp

(

ID_Comp ,

ID_Comp_R ,

Lang_mod

);

CREATE INDEX XIF9Prom_Mod_Repl_Comp ON Prom_Mod_Repl_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Imag_Comp CASCADE CONSTRAINTS;

CREATE TABLE Imag_Comp (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

Kind_Repres NUMBER NOT NULL,

Fale_Image BLOB NOT NULL

);

DROP INDEX XPKImag_Comp;

CREATE UNIQUE INDEX XPKImag_Comp ON Imag_Comp

(

ID_Comp ,

ID_Comp_R ,

Kind_Repres

);

DROP TABLE Grapf_Repr_Comp CASCADE CONSTRAINTS;

CREATE TABLE Grapf_Repr_Comp (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

Kind_repres NUMBER NOT NULL,

Repres_Comp VARCHAR2(250) NOT NULL

);

DROP INDEX XPKGrapf_Repr_Comp;

DROP INDEX XIF8Grapf_Repr_Comp;

CREATE UNIQUE INDEX XPKGrapf_Repr_Comp ON Grapf_Repr_Comp

(

ID_Comp ,

ID_Comp_R ,

Kind_repres

);

CREATE INDEX XIF8Grapf_Repr_Comp ON Grapf_Repr_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Cond_Oper_Comp CASCADE CONSTRAINTS;

CREATE TABLE Cond_Oper_Comp (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

Verb_Descr_Cond VARCHAR2(250) NOT NULL

);

DROP INDEX XPKCond_Oper_Comp;

CREATE UNIQUE INDEX XPKCond_Oper_Comp ON Cond_Oper_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Specif_Comp CASCADE CONSTRAINTS;

CREATE TABLE Specif_Comp (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

ID_Specif NUMBER NULL,

Ind_Inter_Specif NUMBER NOT NULL

);

DROP INDEX XPKSpecif_Comp;

DROP INDEX XIF6Specif_Comp;

CREATE UNIQUE INDEX XPKSpecif_Comp ON Specif_Comp

(

ID_Comp ,

ID_Comp_R ,

ID_Specif

);

CREATE INDEX XIF6Specif_Comp ON Specif_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Target_Inerf_Comp CASCADE CONSTRAINTS;

CREATE TABLE Target_Inerf_Comp (

ID_Comp_R NUMBER NOT NULL,

ID_Comp NUMBER NOT NULL,

ID_Target NUMBER NOT NULL,

Name_Target VARCHAR2(250) NULL,

Type_Target NUMBER NULL,

Min_Value NUMBER NULL,

Max_Value NUMBER NULL,

Period_Rec NUMBER NULL

);

DROP INDEX XPKTarget_Inerf_Comp;

DROP INDEX XIF5Target_Inerf_Comp;

CREATE UNIQUE INDEX XPKTarget_Inerf_Comp ON Target_Inerf_Comp

(

ID_Comp_R ,

ID_Comp ,

ID_Target

);

CREATE INDEX XIF5Target_Inerf_Comp ON Target_Inerf_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Entr_Interf_Comp CASCADE CONSTRAINTS;

CREATE TABLE Entr_Interf_Comp (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

ID_Enterf NUMBER NOT NULL,

Name_Enterf VARCHAR2(250) NOT NULL,

Type_input NUMBER NOT NULL,

Min_value NUMBER NULL,

Max_value NUMBER NOT NULL,

Period_Rec NUMBER NOT NULL

);

DROP INDEX XPKEntr_Interf_Comp;

DROP INDEX XIF4Entr_Interf_Comp;

CREATE UNIQUE INDEX XPKEntr_Interf_Comp ON Entr_Interf_Comp

(

ID_Comp ,

ID_Comp_R ,

ID_Enterf

);

CREATE INDEX XIF4Entr_Interf_Comp ON Entr_Interf_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Behev_Comp CASCADE CONSTRAINTS;

CREATE TABLE Behev_Comp (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

Kind_Desc_Behav_Comp NUMBER NOT NULL,

Desc_Behav_Comp VARCHAR2(250) NOT NULL

);

DROP INDEX XPKBehev_Comp;

CREATE UNIQUE INDEX XPKBehev_Comp ON Behev_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Dem_Comp CASCADE CONSTRAINTS;

CREATE TABLE Dem_Comp (

ID_Comp_R NUMBER NOT NULL,

ID_Comp NUMBER NOT NULL,

ID_Dem NUMBER NULL,

Demand VARCHAR2(250) NOT NULL,

Descript VARCHAR2(250) NOT NULL

);

DROP INDEX XPKDem_Comp;

DROP INDEX XIF1Dem_Comp;

CREATE UNIQUE INDEX XPKDem_Comp ON Dem_Comp

(

ID_Comp_R ,

ID_Comp ,

ID_Dem

);

CREATE INDEX XIF1Dem_Comp ON Dem_Comp

(

ID_Comp ,

ID_Comp_R

);

DROP TABLE Component CASCADE CONSTRAINTS;

CREATE TABLE Component (

ID_Comp NUMBER NOT NULL,

ID_Comp_R NUMBER NOT NULL,

Name_Komp VARCHAR2() NOT NULL,

Date_R_Komp DATE NOT NULL

);

DROP INDEX XPKComponent;

CREATE UNIQUE INDEX XPKComponent ON Component

(

ID_Comp ,

ID_Comp_R

);

Размещено на Allbest.ru