Разработка информационной системы для обеспечения маркетинга инновационно-маркетингового отдела университета

41

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

Введение

С начала 80-х. годов СУБД перестали быть университетскими проектами и начали выходить на рынок как коммерческие продукты. Одной из первых коммерческой SQL-системой стала СУБД ORACLE, выпущенная во второй половине 80-х гг. фирмой Relational Software Incorporated, которая теперь называется ORACLE Corporation. С этого момента начался бурный рост всей отрасли, занимающейся разработкой и использованием интегрированных информационных систем, основанных на концепции автоматизированного банка данных, и развитие корпорации ORACLE в том числе.

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

Производительность СУБД является одним из наиболее важных ее параметров. Говоря о производительности, я имею в виду некую абстрактную величину, обратно пропорциональную времени, которое затрачивает СУБД на определенную операцию по обработке данных. Другим не менее важным параметром СУБД является как можно более компактное хранение данных, обеспечивающее максимальную экономию дискового пространства и уменьшение операций дискового ввода - вывода. СУБД представляет из себя весьма сложную систему, объединяющую множество технологий. В большинстве прикладных систем СУБД можно выделить три логических части: пользовательский интерфейс (средства представления), обеспечивающий функции ввода и отображения данных; некоторую прикладную обработку, характерную для данной предметной области, и собственно сервисы СУБД. Суть проблемы заключается в том, что чаще всего уже есть готовое приложение, которое работает под управлением СУБД ORACLE. Но из-за неточного технического задания, ошибок на этапе проектирования и разработки, изменения структуры или некоторых концепций этого приложения эффективность его работы оставляет желать лучшего.

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

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

В данном дипломном проекте была поставлена задача: разработать информационную систему для обеспечения маркетинга инновационно-маркетингового отдела университета. Эта система предназначена для систематизации информации, которая используется в работе отдела.

Программа разрабатывается с использованием современной системы управления базами данных Oracle 9i. Эта система является одной из самых мощных на сегодняшний день и идеально подходит для проектов такого рода.

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

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

1. Постановка задачи

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

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

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

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

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

2. Теоретическая часть

2.1 Модели, информация и данные

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

По своей "физической" природе различают модели физические (одной природы с оригиналом), предметно-математические (имеющие отличную от оригинала природу, но эквивалентные ему в смысле математического описания), знаковые (построенные в виде упорядоченной совокупности символов - знаков: схемы, формулы, тексты, графики и т.п.) и мысленные.

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

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

Второй "мир" - область идей и информации, существующих в представлении субъектов информационно - познавательной деятельности (в контексте АИС - это разработчики программных и информационных средств, пользователи и т.д.). Мысленные модели находят свое непосредственное выражение в виде концептуальных моделей. Концептуальная модель - это знаковая модель, в которой понятийным образам объектов сопоставляются совокупности символов (знаки). Характерным для этого класса моделей является использование знаков для обозначения обобщенных (абстрактных) понятий об объектах - так называемых концептов. Концептам приписываются атрибуты, соответствующие свойствам объектов ПрО. Соответственно, каждый концептуальный объект будет характеризоваться совокупностью значений атрибутов.

Так же как и сама ПрО, ее концептуальная модель находится в постоянном движении. Следует однако заметить, что при этом время чаще всего рассматривается как один из атрибутов объекта; таким образом, при необходимости отобразить состояние объекта в некоторый момент времени в модели каждому такому состоянию будет соответствовать экземпляр объекта с заданным значением атрибута ВРЕМЯ.

Заметим также, что изменения в концептуальной модели обусловлены не только изменениями в отображаемой ПрО, но и изменениями в представлениях субъектов моделирования (изменениями информационных потребностей пользователей).

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

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

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

2.2 Табличные пространства

автоматизация маркетинг отдел университет oracle

Используемые данные базы данных ORACLE логически хранятся в ТАБЛИЧНЫХ ПРОСТРАНСТВАХ (TABLESPACE), а физически располагаются в ФАЙЛАХ ДАННЫХ, ассоциированных с соответствующим табличным пространством.

Файлы данных - физические структуры, каждая из которых связана с одним табличным пространством

Объекты - Хранятся в табличных пространствах, и могут располагаться в нескольких файлах данных

Каждая база данных ORACLE подразделяется на логические элементы, называемые ТАБЛИЧНЫМИ ПРОСТРАНСТВАМИ(TABLESPACE). Администратор базы данных может использовать табличные пространства для:

· управления распределением памяти для объектов базы данных

· установления квот памяти для пользователей базы данных

· управления доступностью данных, путем перевода отдельных табличных пространств в состояния online или offline

· копирования и восстановления данных

· распределения данных по устройствам для повышения производительности

Табличное пространство SYSTEM

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

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

Онлайновые и офлайновые табличные пространства

АБД может перевести любое табличное пространство в базе данных ORACLE в состояние ОНЛАЙН (т.е. доступно) или ОФЛАЙН (недоступно), если база данных открыта. Единственным исключением является то, что табличное пространство SYSTEM всегда находится в онлайне, ибо словарь данных должен быть всегда доступен ORACLE. Обычное состояние табличного пространства - онлайн, так что данные, содержащиеся в нем, доступны пользователям базы данных. Однако администратору может понадобиться перевод табличного пространства в офлайн по одной из следующих причин:

1) чтобы сделать часть базы данных недоступной, сохраняя в то же время нормальный доступ к остальной части

2) чтобы выполнить резервное копирование офлайнового табличного пространства (хотя такое копирование можно осуществлять и в онлайне, одновременно с использованием табличного пространства)

3) чтобы сделать приложение вместе с его группой таблиц временно недоступным на время обновления или сопровождения этого приложения

Когда табличное пространство переводится в офлайн, ORACLE не позволяет последующим предложениям SQL обращаться к объектам этого табличного пространства.

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

2.3 Файлы данных

Табличное пространство в базе данных ORACLE состоит из одного или нескольких физических ФАЙЛОВ ДАННЫХ. Файлы данных, ассоциированные с табличным пространством, хранят все данные этого табличного пространства. Любой файл данных может ассоциироваться только с одним табличным пространством и только с одной базой данных. При создании файла данных для табличного пространства ORACLE распределяет ему указанное количество дисковой памяти. Когда файл данных создается, операционная система несет ответственность за очистку старой информации и за установку должных режимов доступа к файлу, прежде чем он будет распределен ORACLE. Если файл велик, этот процесс может потребовать значительного времени. Поскольку первым табличным пространством в любой базе данных всегда является SYSTEM, первые файлы данных любой базы данных автоматически распределяются табличному пространству SYSTEM во время создания базы данных.

Содержимое файла данных

После первоначального создания файла данных соответствующее дисковое пространство еще не содержит никаких данных; однако это пространство ЗАРЕЗЕРВИРОВАНО за будущими сегментами ассоциированного табличного пространства - оно не может содержать каких-либо иных данных. Когда сегмент (например, сегмент данных таблицы) будет создан и начнет увеличиваться в размерах, ORACLE использует свободное место в соответствующих файлах данных, чтобы распределять экстенты для этого сегмента. Данные в сегментах объектов (сегментах данных, сегментах индексов, сегментах отката и т.д.) в табличном пространстве физически хранятся в одном или нескольких файлах данных, составляющих это табличное пространство.

Офлайновые файлы данных

Табличные пространства в любой момент можно переводить в ОФЛАЙН (т.е. делать недоступными) или в ОНЛАЙН (делать доступными). Поэтому все файлы данных, составляющие табличное пространство, переводятся в офлайн или онлайн одновременно, всей группой. Индивидуальные файлы данных также могут быть переведены в офлайн; однако это обычно делается лишь при некоторых процедурах восстановления базы данных.



2.4 Схемы и объекты схемы

СХЕМА(SCHEMA) - это коллекция объектов. ОБЪЕКТЫ СХЕМЫ - это логические структуры, непосредственно относящиеся к данным базы данных. Объекты схемы включают такие структуры как: таблицы, представления, последовательности, хранимые процедуры, синонимы, индексы, кластеры и связи баз данных. (Не существует взаимосвязи между табличным пространством и схемой; объекты одной и той же схемы могут находиться в разных табличных пространствах, и одно и то же табличное пространство может содержать объекты из разных схем.)

ТАБЛИЦА(TABLE) - это основная единица хранения данных в базе данных ORACLE. Таблицы базы данных хранят все данные, доступные пользователям. Данные таблицы хранятся в виде СТРОК и СТОЛБЦОВ. Каждая таблица определяется с ИМЕНЕМ ТАБЛИЦЫ и набором столбцов. Каждому столбцу дается ИМЯ СТОЛБЦА, ТИП ДАННЫХ (такой как CHAR, DATE или NUMBER), а также ШИРИНА (которая может быть предопределена типом данных, как в случае DATE) или МАСШТАБ и ТОЧНОСТЬ (только для типа данных NUMBER). После того, как таблица создана, в нее могут быть вставлены строки действительных данных. После этого строки таблицы можно опрашивать, удалять или обновлять. Чтобы учредить организационные правила для данных таблицы, для таблицы можно также определить ограничения целостности и триггеры.

ПРЕДСТАВЛЕНИЯ(VIEW) - это настроенное представление данных из одной или нескольких таблиц. представлений можно рассматривать как "хранимый запрос". Представления в действительности не содержат данных; вместо этого они доставляют данные из тех таблиц, на которых они основаны (так называемых БАЗОВЫХ ТАБЛИЦ представлений). Базовые таблицы, в свою очередь, могут быть как таблицами, так и представлениями.

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

ПОСЛЕДОВАТЕЛЬНОСТЬ(SEQUENCE) - генерирует уникальные порядковые номера, которые могут использоваться как значения числовых столбцов таблиц базы данных. Последовательности упрощают прикладное программирование, автоматически генерируя уникальные числовые значения для строк одной или нескольких таблиц. Номера, генерируемые последовательностью, независимы от таблиц, так что одну и ту же последовательность можно использовать для нескольких таблиц. После ее создания, к последовательности могут обращаться различные пользователи, чтобы получать действительные порядковые номера.

Термином "программная единица" обозначаются хранимые процедуры, функции и пакеты.

ПРОЦЕДУРА(PROCEDURE) или ФУНКЦИЯ(FUNCTION) - это совокупность предложений SQL и PL/SQL, сгруппированных вместе как выполнимая единица, исполняющая специфическую задачу.

Процедуры и функции сочетают легкость и гибкость SQL с процедурными возможностями языка структурного программирования. С помощью PL/SQL такие процедуры и функции можно определять и сохранять в базе данных для продолжительного использования.

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

ПАКЕТЫ(PACKAGE) дают метод инкапсулирования и хранения взаимосвязанных процедур, функций и других конструктов пакета как единицы в базе данных. Предоставляя администратору базы данных или разработчику приложений организационные преимущества, пакеты в то же время расширяют функциональные возможности, и увеличивают производительность базы данных.

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

КЛАСТЕРЫ(CLUSTER) предоставляют необязательный способ хранения данных таблиц. Кластер - это группа из одной или нескольких таблиц, физически хранящихся вместе.

Взаимосвязанные столбцы таблиц в кластере называются КЛЮЧОМ КЛАСТЕРА. Ключ кластера индексируется, так что строки кластера могут извлекаться с минимальными затратами на ввод-вывод. Поскольку данные ключа кластера в индексированном (не кэшированном) кластере хранятся в одном экземпляре для всех таблиц кластера, достигается экономия пространства по сравнению с обычными (некласте- ризованными) таблицами.

Кластеризованные таблицы: Связанные данные хранятся вместе, более эффективно Некластеризованные таблицы: Связанные данные хранятся отдельно, занимая больше места.

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

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

2.5 Блоки данных, экстенты и сегменты

Блоки данных

На самом низком уровне рассмотрения, данные базы данных ORACLE хранятся в БЛОКАХ ДАННЫХ (называемых также логическими блоками, блоками ORACLE или страницами). Один блок данных соответствует фиксированному числу байт физического пространства базы данных на диске. Размер блока данных специфически устанавливается для каждой базы данных ORACLE при ее создании. Этот размер кратен размеру блока операционной системы, но не превышает определенный максимум. Важно помнить, что база данных, на ее самом низком уровне, использует и распределяет свободное пространство в базе данных блоками данных ORACLE. По контрасту с этим, все данные на физическом уровне, т.е. на уровне операционной системы, распределяются в байтах. Каждая операционная система имеет то, что называется РАЗМЕРОМ БЛОКА, который определяется как специфическое число байт на диске.

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

Формат блока данных ORACLE один и тот же, независимо от того, содержит ли блок данные таблицы, индекса или кластера.

Экстенты

Следующий уровень логического пространства базы данных называется ЭКСТЕНТОМ(EXTENTS). Экстент - это специфическое число смежных блоков данных, распределяемых для хранения специфического типа информации.

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

Сегменты

Уровень логического пространства базы данных, следующий за экстентом, называется СЕГМЕНТОМ (SEGMENTS). Сегмент - это совокупность экстентов, распределенных для специфического типа структуры данных, и находящихся в одном и том же табличном пространстве. Например, данные каждой таблицы хранятся в ее собственном СЕГМЕНТЕ ДАННЫХ, а данные каждого индекса хранятся в его собственном СЕГМЕНТЕ ИНДЕКСА.

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

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

База данных ORACLE может содержать четыре различных типа сегментов:

1. сегмент данных

2. сегмент индекса

3. сегмент отката

4. временный сегмент

2.6 Структуры памяти и процессы

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

ПРОЦЕССЫ(PROCESS) - это задания или задачи, работающие в памяти этих компьютеров. ПРОЦЕСС - это "канал управления", или механизм в операционной системе, способный выполнять последовательность шагов. Некоторые операционные системы используют термины "задание" или "задача". Процесс обычно имеет свою собственную личную область памяти, в которой он выполняется. (V$PROCESS - информация об активных и V$BGPROCESS - информация о фоновых процессах)

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

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

Структуры памяти

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

2.7 Словарь данных

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

Введение в словарь данных

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

1. имена пользователей ORACLE

2. привилегии и роли, которые были предоставлены каждому пользователю

3. имена объектов схем (таблиц, представлений, снимков, индексов, кластеров, синонимов, последовательностей, процедур, функций, пакетов, триггеров и т.д.)

4. информацию об ограничениях целостности

5. умалчиваемые значения для столбцов

6. сколько пространства было распределено и в настоящее время используется объектами в базе данных

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

8. другую общую информацию о базе данных

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

Структура словаря данных

В состав словаря данных базы данных входят:

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

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

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

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

Вы можете добавлять в словарь данных новые таблицы или представления. Если вы добавляете новые объекты в словарь данных, их владельцем должен быть SYSTEM или какой-либо третий пользователь ORACLE. Когда включен режим аудита, эта таблица может неограниченно расти. Хотя пользователи не должны удалять эту таблицу, администратор безопасности может удалять из нее данные, потому что строки этой таблицы служат лишь для информации и не являются необходимыми для работы ORACLE.

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

Словарь данных всегда доступен при открытой базе данных. Он размещается в табличном пространстве SYSTEM, которое всегда находится в состоянии онлайн, когда база данных открыта.

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

Префикс	Назначение
USER	обзор пользователя (что есть в схеме пользователя)
ALL	расширенный обзор пользователя (к чему есть доступ)
DBA	обзор администратора (к чему все пользователи имеют доступ)

3. Специальная часть

3.1 Анализ предметной области

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

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

Технология проектирования определяется как совокупность трех составляющих:

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

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

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

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

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

· технология должна поддерживать полный ЖЦ ПО;

· технология должна обеспечивать гарантированное достижение целей разработки ИС с заданным качеством и в установленное время;

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

· технология должна обеспечивать возможность ведения работ по проектированию отдельных подсистем небольшими группами (3-7 человек). Это обусловлено принципами управляемости коллектива и повышения производительности за счет минимизации числа внешних связей;

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

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

· технология должна обеспечивать независимость выполняемых проектных решений от средств реализации ИС (систем управления базами данных (СУБД), операционных систем, языков и систем программирования);

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

3.2 Сущность структурного подхода

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

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

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

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

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

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

	1) SADT (Structured Analysis and Design Technique) модели и соответствующие функциональные диаграммы (подраздел 2.2);
	2) DFD (Data Flow Diagrams) диаграммы потоков данных (подраздел 2.3);
	3) ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь" (подраздел 2.4).

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм.

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



3.3 Методология функционального моделирования SADT

Методология SADT разработана Дугласом Россом и получила дальнейшее развитие в работе [4]. На ее основе разработана, в частности, известная методология IDEF0 (Icam DEFinition), которая является основной частью программы ICAM (Интеграция компьютерных и промышленных технологий), проводимой по инициативе ВВС США.

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

	1) графическое представление блочного моделирования. Графика блоков и дуг SADT-диаграммы отображает функцию в виде блока, а интерфейсы входа/выхода представляются дугами, соответственно входящими в блок и выходящими из него. Взаимодействие блоков друг с другом описываются посредством интерфейсных дуг, выражающих "ограничения", которые в свою очередь определяют, когда и каким образом функции выполняются и управляются;
	2) строгость и точность. Выполнение правил SADT требует достаточной строгости и точности, не накладывая в то же время чрезмерных ограничений на действия аналитика. Правила SADT включают:
	- ограничение количества блоков на каждом уровне декомпозиции (правило 3-6 блоков);
	-связность диаграмм (номера блоков);
	-уникальность меток и наименований (отсутствие повторяющихся имен);
	-синтаксические правила для графики (блоков и дуг);
	-разделение входов и управлений (правило определения роли данных).
	-отделение организации от функции, т.е. исключение влияния организационной структуры на функциональную модель.

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

Далее был проведен анализ работы отдела при помощи Case средства BPWin.

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

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

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

3.4 Моделирование при помощи ERWin

Для построения ER-диаграммы («Entity-Relation» - «сущность-связь») будем использовать CASE-пакет ERWin, в возможности которого входит генерация готовой базы данных на основе построенной двухуровневой модели данных.

Создание базы данных при помощи ERWin состоит из трех этапов:

- построение логической модели;

- построение физической модели;

- генерация базы данных для выбранного сервера;

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

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

3.5 Выбор среды программирования

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

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

Delphi разработан как продукт, ориентированный на реализацию следующих тенденций.

Одно направление - объектно-ориентированный подход, хорошо структурирующий как саму задачу, так и ее решение в виде прикладной системы.

Другое направление, возникшее во многом благодаря объектной ориентации, - визуальные средства быстрой разработки приложений (RAD - Rapid Application Development), основанные на компонентной архитектуре.

Третья тенденция - использование компиляции, а не интерпретации. Это объясняется тем, что скоростные характеристики компилируемых приложений в десятки раз лучше, чем у систем, использующих интерпретатор. При этом повышается легкость отчуждаемости готовых систем, так как отпадает необходимость «таскать за собой» сам интерпретатор (run-time), выполненный обычно в виде динамической библиотеки и занимающий в лучшем случае несколько сотен килобайт (а в большинстве случаев - два-три мегабайта). Отсюда и меньшая ресурсоемкость у скомпилированных систем.

Четвертая тенденция - возможность работы с базами данных универсальными методами. Если попытаться оценить процент систем, которые так или иначе требуют обработки структурированной информации (как для внутрикорпоративного использования, так и для коммерческого или иного распространения), то окажется, что цифра 60-70% может представлять лишь нижнюю границу. Важным свойством средств обеспечения доступа к базам данных является их масштабируемость, то есть возможность не только количественного, но и качественного роста системы.

Среда Delphi умеет не только использовать, но и создавать DLL, а ее программы могут как инициировать, так и обрабатывать практически любые события Windows. Компоненты Delphi написаны в среде Delphi, поэтому не нужно выходить из системы, чтобы создавать новые компоненты или дорабатывать существующие. Более того, находясь в среде Delphi, можно даже использовать компоненты ActiveX, так как программы, созданные в Delphi, прекрасно работают с компонентами ActiveX. Пользователи Delphi имеют такие возможности настройки компонентов ActiveX, которые VB предоставить не в состоянии.

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

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

Delphi всегда обладала мощным потенциалом в сфере создания баз данных. Delphi вводит концепцию распределенного набора данных, который взаимодействует со всеми типами баз данных в режиме клиент/сервер, то есть приложение-клиент сохраняет локальную копию таблицы и просто пересылает модификацию на сервер. Благодаря этому упрощению программе требуется поддержка только одного объекта клиента, инкапсулированного в новый объект TMemoryDataSet. Весь остальной код остается в распоряжении BDE, которая используется параллельно работающими приложениями.

Delphi гостеприимно распахивает двери своего «золотого фонда» компонентов работы с данными, превращая программирование баз данных почти в тривиальную задачу. И все это достигается благодаря системе доступа к базам данных фирмы Borland (Borland Database Engine, или BDE).

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

3.6 Администрирование Oracle

3.6.1 Представление о количестве таблиц Oracle

Инсталляция Oracle под Linux или Windows очень полезна для получения представления о программном обеспечении и его использовании. Oracle регулярно изменяет функциональные характеристики программного обеспечения на нижних уровнях. Посмотрите на изменение от версии к версии структуры, объемов и количества X$-таблиц, в которых хранится вся служебная информация.

Версия Oracle	Количество X$-таблиц
6	? (35)
7	126
8	200
8i	271
9i	352

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

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

3.6.2 Резервные копии баз данных и базы данных разработчиков

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

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

Типы резервных копий Oracle

Существует три основных вида резервирования Oracle:

Экспорт: инструментальное средство Oracle exp используется для извлечения данных из базы данных в файл операционной системы. Формат файла нестандартный и будет обсуждаться в разделе “Журнальные, трассировочные, экспортные, сигнальные и управляющие файлы” (во второй части статьи - ред.). Инструментальное средство Oracle imp вставляет данные назад в ту же самую или другую базу данных. Можно выполнять частичный или полный экспорт всей базы данных. В полный экспорт включаются хешированные пароли. Если целью является кража данных, то достаточно выполнить экспорт схемы владельца приложения.