Oracle введение в проектирование информационных систем


Содержание

Глава 15. Введение в проектирование кода

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

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

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

Как проектировать модули кода? Обычно это делается в несколько этапов, причем на каждом вносятся уточнения, основанные на опыте и знании того, как будет работать система. Часто уточнение является прямым следствием создания макетов в процессе проектирования.

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

Объем и содержание информации, полученной при функциональном анализе, очень зависят как от методики, так и от особенностей проекта. Некоторые аналитики любят рисовать планы экранных форм. Если это сделает их счастливыми — прекрасно, но наш опыт показывает , что окончательный продукт может быть совершенно не похож на эти чертежи. Точно так же окончательный код, вероятно, совершенно не будет похож на SQL-предложения и псевдокод, так заботливо предоставленный проектировщиками.

Начнем с рассмотрения иерархии функций. Этот прием анализа позволяет сформулировать требования на самом высоком уровне, а затем разбивать каждое утверждение на более мелкие составляющие до тех пор, пока не будут выявлены «атомарные» функции. На рис. 15.1 показан фрагмент иерархии функций для заявлений о выплате страхового возмещения, обрабатываемых гипотетическим страховым приложением. На этой упрощенной схеме показана только одна функция этого приложения — обработка заявлений, и в тексте мы также описываем только одну из функций (шаг 2.2).

Рис. 15.1 Иерархия функций для обработки заявлений о выплате страхового возмещения

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

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

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

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

В классическом приложении Oracle Method такое дублирование означает ошибку анализа. Если говорить более конкретно, то дублирование обычно является признаком того, что аналитик спутал функцию с механизмом. Например, может обнаружиться, что уведомление о заявлении по почте описано не в той части иерархии, где описано уведомление по телефону. Естественно, эта ошибка означает, что механизм (почтовая служба, телефонная сеть) спутан с функцией (получение уведомления о заявлении). Если в процедуре обработки уведомлений этих типов есть различия, то их можно детализировать в рамках одной функции — «Получить уведомление о заявлении».

Помимо разработки иерархии функций (в которой есть только краткие их описания), аналитик должен написать текстовое пояснение к каждой функции. На каждом уровне иерархии это, возможно, и не понадобится, но вот для верхнего уровня (в нашем примере — «Обработать заявление») и для нижнего, или атомарного, уровня (2.2.1—2.2.5) это обязательно. Пример описания приведен ниже.

Пример 15.1. Краткий пример функционального определения

2.2.2. Проверить, обеспечено ли заявление

Получить и зарегистрировать все подробные сведения о заявлении ( Claims Details), включая все подробные сведения о третьих сторонах ( Third Party) и свидетелях ( Witness). Изучить полис ( Policy) на предмет наличия исключений ( Exclusion Clauses) и определить, действуют ли они для данного заявления ( Claim).

Если есть исключение, закрыть заявление и сгенерировать стандартное письмо ( Standard Letter) заявителю ( Claimant). Если такого исключения нет, изменить статус заявления на «ожидающее оценки » ( Awaiting Estimate), назначить и уведомить оценщика размера убытка ( Loss Adjuster).

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

Имена сущностей, используемые в примере 15.1, не стандартизованы. Они сформулированы так, чтобы пример был понятен, а не в расчете на соответствие какой-либо конкретной методике.

Другие результаты анализа

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

Конечно, выделение имен сущностей в описаниях функций помогает понять назначений функций, однако существует более строгий подход к достижению этого понимания — построение полной матрицы «функции-сущности». Форма матрицы позволяет найти информацию о конкретной функции или конкретной сущности и провести проверку качества, т.е. проверку того, имеет ли каждая сущность конструктор, или источник (функцию, которая создает ее экземпляры), есть ли ссылки на эту сущность (т.е. используется ли она) и имеет ли она деструктор. Во многих случаях деструктором является комплект программ архивации, однако гораздо чаще он просто отсутствует. Процесс анализа ссылок на сущности обозначают аббревиатурой CRUD (Create, Reference, Update, Delete — создание, ссылка, обновление, удаление).

Иногда эту информацию разбивают дальше, получая в итоге матрицу «функции-атрибуты». Для достижения этого уровня детализации нужно много времени, и мы сомневаемся, что эти затраты всегда оправданы. В результате трансформации, выполняемой на этапе проектирования, часто получается, что матрица «функции-атрибуты» мало чем напоминает итоговую матрицу «модули-столбцы «. Тем не менее, такая работа все же полезна, так как позволяет еще раз проверить качество анализа, а именно — убедиться, что каждый атрибут в модели сущностей имеет источник и используется. Она также может оказаться очень полезной при определении обоснованности разбиения одной таблицы на две (т.е. вертикального секционирования). Если видно, что два набора атрибутов используются разными наборами функций, то вполне можно создать две сущности, совместно использующие первичный ключ.

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

Отображение функций в модули

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

1. Начать анализ с рассмотрения функций.

2. Завершить анализ построением модели сущностей, поддерживающей эти функции.

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

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

Рис. 15.2. Шаги, необходимые для выхода на этап проектирования модулей

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

Рис. 15.3. Эффект лабиринта при отображении функций в модули

Одни функции достаточно похожи друг на друга по выполняемым действиям, и их можно и нужно объединить в общий модуль, даже если их результат или контекст — абсолютно разные. Другие функции сложны, и их нужно разбивать на более мелкие и управляемые компоненты. Иногда в функциональные описания «завернуты» правила обработки данных, которые можно реализовать как ограничения на таблицах или триггеры, а не как прикладные модули. Это распространит их действие на всю систему (а не только на приложение). Некоторые функции будут реализованы как чисто ручной процесс и вообще не будут отображены ни в какие модули.

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

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

• ограничения — для реализации правил обработки данных без процедурного кода;

• триггеры базы данных — для процедурного ввода правил обработки данных для всех частей приложения;

• хранимые процедуры — для инкапсуляции общих бизнес-функций;

• идентичность SQL. (лучше всего достигается с помощью хранимых процедур) — для использования разделяемой области SQL.

Не забудьте о системных модулях

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

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

• диспетчер пакетных очередей/планировщик заданий;

• диспетчер очередей на печать;

• средство доступа к данным или средство создания нерегламентированных запросов;

• менеджер каталогов файловой системы;

• процедуры автоматического резервного копирования;

• процедуры автоматического восстановления;

• средство предоставления доступа пользователям и аннулирования доступа;

• средство настройки среды для нового пользователя;

• средство, позволяющее пользователям изменять свой пароль;

• средства управления приложениями.

Некоторые из этих функций может выполнять операционная система, но операционные системы в этом отношении очень отличаются. Например, возникает вопрос, насколько гибко построена в той или иной системе обработка очередей на печать? Необходимо также подумать о том, а будут ли пользователи иметь доступ к средствам операционной системы. Даже если будут, то должны ли они будут выходить из приложения для того, чтобы посмотреть на очередь на печать, а затем вновь вызывать его? Будут ли пользователи иметь возможность доступа к Unix-очереди на печать из команды lpstat ? (А действительно, может ли кто-нибудь это сделать?) Даже если на первый взгляд кажется, что операционная система поддерживает некоторые необходимые пользователю функции, как правило, все равно приходится выполнять дополнительный объем работы (особенно с очередями на печать) хотя бы для создания удобной для пользователя надстройки над некоторыми системными функциями.

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

Наличие средств доступа к данным является обязательным требованием в современных проектах. Сегодня пользователи более сведущи в вычислительной технике, чем раньше, и они хотят иметь на своих рабочих места самые новейшие средства. Они рассчитывают на обработку информации новаторскими, необычными способами, и вам предстоит принять здесь важное решение. Хотите ли вы, чтобы ваши пользователи направляли ИУС-запросы к рабочим данным, которые могут замедлить другие текущие операции? Или же лучше извлечь данные и поместить их в копию базы данных либо в хранилище данных? Эта тема рассматривается в главе 13.

Вернемся к средствам создания запросов. Таких продуктов сейчас очень много: Oracle Data Query, Oracle Data Browser (вместе они называются Discoverer/2000), Business Objects, Cognos Impromptu и т.д. Не допускайте ошибку, предполагая, что можно просто инсталлировать эти средства на ПК пользователей и отправиться гулять. Чтобы с этими продуктами можно было работать, требуется значительный объем работ по настройке. Например, необходимо присвоить столбцам подходящие псевдонимы и создать логические представления (либо в рамках продукта, либо как представления Oracle), чтобы отчасти скрыть сложность базы данных. Пример — предварительное соединение двух и более таблиц в представлении. Эту операцию иногда называют созданием уровня отображения для данного продукта (в Business Objects его называют universe — «вселенная», просто чтобы подчеркнуть, насколько он важен).

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

Ваш конечный пользователь, скорее всего, не собирается выделять ассигнования на приглашение постоянного администратора БД для управления СУБД Personal Oracle 7 на однопользовательском ПК или в сети Novell NetWare с тремя пользователями. Если у вас на предприятии 10000 таких систем, можете быть совершенно уверены, что у ваших постоянных администраторов БД не будет свободного времени, чтобы смотреть друг за другом. Поэтому сегодня существует общее требование: создать для таких функций удобный интерфейс, который будет выполнять простую работу и скрывать лежащую за ней сложность. Oracle сама признала этот факт и стремится предоставить как можно больше этих возможностей в базовом продукте, но конечная цель пока не достигнута, поэтому вам, возможно, придется самому добавлять те или иные функции. Для большой сети со множеством узлов можно попробовать приобрести средство для удаленного управления приложениями (например, PATROL фирмы ВМС), которое дополнит сервисы, имеющиеся в Oracle Enterprise Manager.

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

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

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

SELECT job
, log_user
FROM dba_jobs
WHERE broken = ‘Y’;

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

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

Управление исходным кодом и версиями

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

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

Управление базой данных

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

И так понятно (но мы все равно это подчеркнем), что любой код, Разработанный по этому первому варианту, имеет все шансы окончить свое существование в мусорной корзине! По этой причине мы иногда используем термин «итеративная разработка» вместо слова «макетирование», чтобы привлечь внимание руководителей к тому неприятному факту, что как бы им ни нравился первый вариант, его придется выбросить. Если они будут сопротивляться, спросите, не хотели бы они полетать на макете самолета.

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

Мы обнаружили, что самый лучший метод (конечно, в среде разработки Oracle) — дать каждому разработчику свою собственную схему (в Oracle7 это то же самое, что и пользовательское имя) и настоять на том, чтобы разработчики применяли синонимы для обращения к объектам в совместно используемой схеме, которую сопровождает администратор БД группы разработчиков. Это — относительно простой способ проверки того, на какие приватные объекты ссылается та или иная схема.

Один из основных моментов, который вы должны согласовать, — как часто повторять команды обновления базы данных и какой механизм использовать для выполнения повторной выдачи. Удовлетворить всех и каждого здесь просто невозможно! Всегда найдется кто-нибудь, кто просто ждет изменений, и кто-нибудь, кто отлаживает критический фрагмент кода и угрожает убить вас, если вы только попробуете сейчас обновить базу данных!

Хороший метод — составить циклический список экземпляров или схем, чтобы администратор БД разработчиков сопровождал, скажем, пять последних определений и при выдаче нового определения затирал самое старое. Для этого нужно обеспечить тесное взаимодействие, и члены бригады должны получать соответствующие уведомления о предполагаемых изменениях и полный их перечень. Достоинство такого подхода в том, что он не дает действовать по методу «смешивания и сопоставления», который может быть результатом описанной выше стратегии использования синонимов (хотя кому-то и может показаться, что именно эта особенность делает стратегию, основанную на синонимах, столь полезной).

Управление исходным кодом

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

Если используются генераторы исходного кода, то в действительности «исходный код» может представлять собой репозитарий или словарь проектирования, а не исходный код, хранящийся в чисто текстовых файлах. Примеры — Oracle Developer/2000 и Microsoft Visual Basic. Даже там, где используются чисто текстовые файлы (например, INP-файлы SQL*Forms версий 2.х и 3.0), система управления исходным кодом может не знать, как вставить свою управляющую информацию в файл, не сделав этот файл недействительным для программы, которая предназначена для его чтения.

Управление исходным кодом может оказаться еще более сложной задачей в средах клиент/сервер, где одна часть кода должна компилироваться на клиенте, а остальные части — на сервере. Чтобы обеспечить синхронность этих двух сред, необходимо планирование и новаторские технические приемы.

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

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

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


Администратор и (или) администратор БД должны будут предоставить разработчикам и тестировщикам регистрационные имена и учетные записи. Группа проектировщиков, поддерживая постоянную связь с администратором БД, должна обеспечить, чтобы каждый класс пользователей был представлен в целевой системе и мог использоваться в системном тесте.

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

Рассмотрим пример, в котором экранные формы разрабатываются с помощью Oracle Forms, а для упрощения этого процесса применяется схема, изображенная на рис. 15.4. У нас есть два шаблона, по которым можно построить новую экранную форму. Один предназначен для простых форм, а другой — для более сложных. Кроме того, мы имеем каталог библиотек PL/SQL, которые могут использоваться и другими приложениями (не Oracle Forms).

Рис. 15 .4. Типичная конфигурация шаблонов для разработки в Oracle Forms

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

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

Проектирование процесса тестирования

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

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

Разработка стратегии тестирования

При тестировании должны использоваться тесты следующих категорий:

• автономные тесты (тесты модулей);

• тесты связей (проверка стыковки двух и более взаимосвязанных модулей);

• приемо-сдаточные испытания (часто выполняются пользователем);

• регрессивные тесты (серия «старых» тестов, позволяющих проверить, не привели ли ваши усовершенствования к появлению неожиданных проблем);

• тесты производительности или нагрузочные тесты.

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

Разработка вспомогательных средств тестирования

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

Илон Маск рекомендует:  Угол в CSS

Отметим также, что если во внутренних подпрограммах начинают проявляться дефекты или если их нужно модернизировать, то вам (или вашим несчастным преемникам) придется вновь тестировать вышеупомянутые средства. По этой причине в хороших проектах вспомогательный тестовый код часто считается «еще одной частью системы» и легко доступен из ГПИ для любого пользователя, имеющего право с ним работать. Здесь уместно еще раз напомнить наше кредо: работать умно, а не напряженно.

Использование CASE -средств

Что можно сказать об использовании CASE-средств в проектировании приложений? Давайте рассмотрим, какой уровень функционального описания должен быть введен в CASE-продукт и насколько полезны генераторы кода. Мы также попытаемся сравнить объем работ по обеспечению такой детализации в CASE-средствах и выгоды, которые можно получить от их использования.

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

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

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

Оценивая возможность использования технологии CASE в своем проекте, обязательно определитесь с тем, как вы собираетесь ее применять:

• Хотите ли вы использовать ее просто как репозитарий определений данных?

• Хотите ли вы распространить ее и на хранение определений модулей?

• Хотите ли вы генерировать из определений модулей код?

Выбирая репозитарий, нужно ответить на следующие вопросы:

• Сколько приложений выполняют простые манипуляции с базой данных, а сколько — содержат сложную логику, которую нельзя сгенерировать?

• Какой объем рутинной работы можно реализовать с помощью шаблонов и библиотек кода?

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

• Используете ли вы методы ускоренной разработки приложений (УРП), и окажет ли генератор помощь в поэтапном макетировании?

Генераторы становятся все более и более мощными, и Oracle ставит целью обеспечить 100%-ную генерацию 100% кода в основных приложениях. Это великая цель, но в мире полной генерации достижение, например, уровня 99,95% означает полный провал (даже если это может оказаться исключительно полезным для запуска проекта). Oracle и ее конкуренты пока далеки от достижения показателя 100% — отчасти из-за крайней сложности получения соответствующей функциональным требованиям модели данных. Вернемся, однако, к реальности. Если вам требуется создать большое число простых модулей, то генератор вполне может сэкономить время и дать более согласованный код. Если же перед вами стоит задача создания небольшого числа сложных модулей, то генератор будет тормозом, поскольку первой работой при этом, несомненно, будет изъятие ненужного сгенерированного кода.

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

Вы, возможно, помните наш принцип — «работать умно, а не напряженно». Сражаться три месяца с генератором, чтобы заставить его сделать то, что он не хочет, а затем признать свое поражение — не очень умно если для написания модуля вручную понадобилось бы меньше трех недель!

Большинство из нас беспокоятся о том, что генераторы сделают с нашим кодом, и просто не доверяют им в достаточной степени!

Ответ на вопрос ценой $64000 о соединении CASE-средства с генератором, звучит так. Если можно установить, что генератор способен генерировать модули необходимой сложности, то будут ли затраты на ввод данных в репозитарий меньшими, чем затраты на создание этих же модулей с полной документацией традиционными методами?

* Один из авторов работает в подразделении PATROL Research and Development фирмы BMC Software, поэтому его мнение в этой области вполне можно считать предвзятым.

** См. «Database Fingerprinting» by Chris Johnson, Database Programming and Design , September 1995.

НОВОСТИ ФОРУМА
Рыцари теории эфира
01.10.2020 — 05:20: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education ->
[center][Youtube]69vJGqDENq4[/Youtube][/center]
[center]14:36[/center]
Osievskii Global News
29 сент. Отправлено 05:20, 01.10.2020 г.’ target=_top>Просвещение от Вячеслава Осиевского — Карим_Хайдаров.
30.09.2020 — 12:51: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education ->
[center][Ok]376309070[/Ok][/center]
[center]11:03[/center] Отправлено 12:51, 30.09.2020 г.’ target=_top>Просвещение от Дэйвида Дюка — Карим_Хайдаров.
30.09.2020 — 11:53: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education ->
[center][Youtube]VVQv1EzDTtY[/Youtube][/center]
[center]10:43[/center]

интервью Раввина Борода https://cursorinfo.co.il/all-news/rav.
мой телеграмм https://t.me/peshekhonovandrei
мой твиттер https://twitter.com/Andrey54708595
мой инстаграм https://www.instagram.com/andreipeshekhonow/

[b]Мой комментарий:
Андрей спрашивает: Краснодарская синагога — это что, военный объект?
— Да, военный, потому что имеет разрешение от Росатома на манипуляции с радиоактивными веществами, а также иными веществами, опасными в отношении массового поражения. Именно это было выявлено группой краснодарцев во главе с Мариной Мелиховой.

[center][Youtube]CLegyQkMkyw[/Youtube][/center]
[center]10:22 [/center]

Доминико Риккарди: Россию ждёт страшное будущее (хотелки ЦРУ):
https://tainy.net/22686-predskazaniya-dominika-rikardi-o-budushhem-rossii-sdelannye-v-2000-godu.html

Завещание Алена Даллеса / Разработка ЦРУ (запрещено к ознакомлению Роскомнадзором = Жид-над-рус-надзором)
http://av-inf.blogspot.com/2013/12/dalles.html

[center][b]Сон разума народа России [/center]

[center][Youtube]CLegyQkMkyw[/Youtube][/center]
[center]10:22 [/center]

Доминико Риккарди: Россию ждёт страшное будущее (хотелки ЦРУ):
https://tainy.net/22686-predskazaniya-dominika-rikardi-o-budushhem-rossii-sdelannye-v-2000-godu.html

Завещание Алена Даллеса / Разработка ЦРУ (запрещено к ознакомлению Роскомнадзором = Жид-над-рус-надзором)
http://av-inf.blogspot.com/2013/12/dalles.html

[center][b]Сон разума народа России [/center]

Oracle введение в проектирование информационных систем

Власов Андрей Игоревич, к.т.н., кафедра
«Конструирование и технология производства электронной аппаратуры»
МГТУ им.Н.Э.Баумана, iu4.bmstu.ru.
Лыткин Сергей Леонидович, выпускник факультета
Вычислительной математики и кибернетики МГУ.
Яковлев Владимир Леонидович, кафедра
«Автоматизированные информационные системы» МГТУ им.Н.Э.Баумана, iu5.bmstu.ru.

УДК 681.3
ББК 32.97
Д83

Краткое практическое руководство разработчика информационных систем на базе СУБД Oracle: Библиотечка журнала «Информационные технологии» — М.: изд-во Машиностроение, 2000. — 120 с. ил.

В руководстве приведены краткие сведения о теории реляционных баз данных, практическая методика создания, эксплуатации и администрирования информационных систем на основе СУБД Oracle версий 7.x, 8.x. Рассмотрены основные элементы языка PL/SQL и словаря данных СУБД Oracle версий 7.x, 8.x. Основные принципы работы с синтаксическими конструкциями языка и элементами словаря данных рассмотрены на конкретных практических примерах. Руководство рассчитано на разработчиков прикладных систем под СУБД Oracle версий 7.x, 8.x., студентов, аспирантов и преподавателей, специализирующихся в разработке информационных систем и баз данных архитектур клиент/сервер и интернет/интранет.

Изложенные в пособии материалы являются обобщением материалов лекционных курсов: «Автоматизированные банковские системы: проектирование и эксплуатация» и «Разработка автоматизированных систем управления конструкторско-технологическим проектированием на основе СУБД Oracle», читаемых в МГТУ им.Н.Э.Баумана.

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

Логистическая информационная система фирмы «Oracle»

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

Рубрика Программирование, компьютеры и кибернетика
Вид реферат
Язык русский
Дата добавления 12.04.2020
Размер файла 16,5 K

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

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

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

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

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

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

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

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

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

1. Понятие и состав информационной логистической системы

реляционный информационный таблица

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

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

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

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

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

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

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

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

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


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

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

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

Блок данных — последовательность символов фиксированной длины, используемая для представления данных.

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

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

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

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

— создать новую организационную и управленческую среды;

— стыковка информации различных подразделений;

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

· управление взаимоотношениями с бизнес-партнерами;

А) управление контактами, учет и анализ хода потенциальных сделок;

Б) анализ задолженности (анализ дебиторской и кредиторской задолженности, анализ активности бизнес-партнера);

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

Г) система бизнес-правил (формирование писем-напоминаний о неоплате; отслеживание лимита кредитования; система утверждений и предупреждений).

А) возможность отследить все движение по конкретной партии: место хранения партии, дата производства партии, номер сертификата соответствия на партию, срок гарантии производителя на партию.

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

· управление затратами компании;

· управление финансами компании.

А) система позволяет оперативно получать себестоимость товаров с учетом всех дополнительных затрат: затраты на таможенные платежи, транспортные затраты; прочие затраты, относимые на себестоимость товаров.

Б) распределение доходов и расходов по проектам — позволяет определить финансовые результаты по проектам;

В) распределение доходов и расходов по центрам финансовой ответственности — позволяет определять финансовые результаты работы отдельных подразделений и/или филиалов компании.

Пятерка лидеров мирового ERP-рынка: SAP AG, Oracle, PeopleSoft, SAGE, Microsoft Business Solutions.

3. Логистическая информационная система фирмы «Oracle»

История Oracle началась в легендарной Силиконовой долине, штат Калифорния, США. В 1977 году молодой программист Ларри Эллисон бросил учебу в Йельском университете, чтобы начать собственный бизнес. Ларри Эллисон, в распоряжении которого тогда было всего 1200 долларов, уговорил Боба Майнера и Эда Оутса, своих бывших коллег, создать собственную компанию. До этого все трое разрабатывали по заказу ЦРУ проект под названием Oracle. Так в 1977 году появилась Software Development Lab., вскоре переименованная сначала с Relational Software Inc., а затем — в Oracle.

Компания специализируется на выпуске систем управления базами данных, связующего программного обеспечения и бизнес-приложений (ERP- и CRM-систем, специализированных отраслевых приложений). Наиболее известный продукт компании — Oracle Database, который компания выпускает с момента своего основания. С 2008 года корпорация освоила выпуск интегрированных аппаратно-программных комплексов, а с 2009 года в результате поглощения Sun Microsystems стала производителем серверного оборудования, до этого компания выпускала исключительно программное обеспечение.

По статистическим данным на рынке России лидирующее положение занимает Oracle, так как по статистическим данным за 2010 год, данная СУБД занимает более 60% всего рынка, среди других СУБД и около 30% мирового рынка СУБД.

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

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

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

Oracle Database Enterprise Edition защищает от поломок серверов, сбоев на сайтах, ошибок пользователей и уменьшает время вынужденного простоя. Редакция помогает соответствовать нормативно-правовым документам, проводит аудит, осуществляет прозрачное шифрование данных. Благодаря Oracle Database Enterprise Edition администраторы могут управлять всем жизненным циклом информации в больших базах данных.

Ключевые возможности Oracle Database:

· Real Application Cluster (RAC) обеспечивает работу одного экземпляра базы данных на нескольких узлах grid, позволяя управлять нагрузкой и гибко масштабировать систему в случае необходимости.

· Automatic Storage Management (ASM) позволяет автоматически распределять данные между имеющимися ресурсами систем хранения данных, что повышает отказоустойчивость системы и снижает общую стоимость владения (TCO).

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

· Простые средства разработки. Новый инструмент разработки приложений HTML DB позволит простым пользователям создавать эффективные приложения для работы с базами данных в короткие сроки.

· Самоуправление. Специальные механизмы Oracle Database позволяют самостоятельно перераспределять нагрузку на систему, оптимизировать и корректировать SQL-запросы, выявлять и прогнозировать ошибки.

· Большие базы данных. Теперь максимальный размер экземпляра базы данных Oracle может достигать 8 эксабайт.

· Недорогие серверные системы. Oracle Database может использовать недорогие однопроцессорные компьютеры или модульные системы из “серверов-лезвий”.

· В новой версии базы данных реализована поддержка переносимых табличных пространств, система управления потоками данных Oracle Streams и модель распределенных SQL-запросов. Для переноса существующих баз данных в среду Grid в них не потребуется вносить изменений, что позволяет быстро начать использовать все преимущества Oracle Database.

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

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

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

Модуль Oracle inter Media.

Модуль Oracle inter Media обеспечивает поддержку всех типов данных, в том числе выполнение операций поиска по большим текстовым документам различных форматов.

Компонент Oracle Enterprise Manager

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

Модуль Oracle Advanced Replication Option

Модуль Oracle Advanced Replication Option позволяет выполнять репликацию данных в широком диапазоне возможностей, включая синхронную, асинхронную, каскадную и другие типы репликации.

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

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

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

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

1) Информационные системы и технологии в логистике и управлении цепями поставок: учебное пособие / В.А. Медведев, А.С. Присяжнюк, — СПб: Университет ИТМО, 2020. — 183 с.

2) Дейт. К. Дж. Введение в системы баз данных — Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2009.

3) Фридланд А.Я. Информатика и компьютерные технологии. М: Астрель. 2003.204 с.

4) Логистика: учеб.пособие для студентов вузов / М.Н. Григорьев, А.П. Долгов, С.А. Уваров. — М.: Гардарики, 2006.-463 с.

5) Т.В. Алесинская, Основы логистики. Общие вопросы логистического управления. Учебное пособие.

6) Елманова Н., Федоров А. Oracle и Microsoft SQL Server: прошлое, настоящее и будущее.

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

Подобные документы

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

контрольная работа [25,4 K], добавлен 11.11.2010

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

курсовая работа [1,4 M], добавлен 11.11.2014

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

курсовая работа [2,3 M], добавлен 03.05.2015

Основные области проектирования информационных систем: базы данных, программы (выполнение к запросам данных), топология сети, конфигурации аппаратных средств. Модели жизненного цикла программного обеспечения. Этапы проектирования информационной системы.

реферат [36,1 K], добавлен 29.04.2010

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

курсовая работа [1,1 M], добавлен 19.05.2013

Развитая автоматизированная информационная система как условие обеспечения эффективного функционирования организации. Проектирование и построение информационной логической модели базы данных. Краткая характеристика Access. Разработка структуры таблиц.

курсовая работа [39,6 K], добавлен 27.02.2009

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

курсовая работа [5,4 M], добавлен 17.01.2013

Язык описания данных Oracle. Предназначение базы данных для хранения информации. Создание и изменение таблиц с помощью операторов Create и Alter table. Правила именования таблицы. Операторы Rename и Truncate. Метод создания и удаления представления.

презентация [82,7 K], добавлен 14.02.2014

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

отчет по практике [933,1 K], добавлен 05.12.2012

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

курсовая работа [3,0 M], добавлен 22.12.2014

Основные концепции СУБД Oracle


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

Сервер ORACLE обеспечивает эффективные и действенные решения для основных средств баз данных:

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

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

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

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

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

— ORACLE удовлетворяет промышленно принятым стандартам по языку доступа к данным, операционным системам, интерфейсам с пользователем и сетевым протоколам. Это «открытая» система, которая защищает инвестиции заказчика. Сервер ORACLE7 был сертифицирован Национальным институтом стандартов и технологий США как 100%-совместимый со стандартом ANSI/ISO SQL89. ORACLE7 полностью удовлетворяет требованиям правительственного стандарта США FIPS127-1 и имеет «маркировщик» для подчеркивания нестандартных применений SQL. Кроме того, ORACLE7 был оценен Правительственным национальным центром компьютерной безопасности (NCSC) как совместимый с критериями защиты Оранжевой книги; сервер ORACLE7 и Trusted ORACLE7 отвечают соответственно как уровням C2 и B1 Оранжевой книги, так и сравнимым с ними европейским критериям защиты ITSEC.

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

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

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

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

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

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

Физическая и логическая структура ORACLE

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

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

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

Логическая структура базы данных ORACLE определяется:

— одним или несколькими табличными пространствами;

— объектами схем базы данных (таблицами, обзорами, индексами, кластерами, последовательностями, хранимыми процедурами).

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

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

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

СУБД Oracle имеет собственный язык PL/SQL

PL/SQL — это принадлежащее фирме Oracle процедурное языковое расширение языка SQL. PL/SQL сочетает легкость и гибкость SQL с процедурными возможностями языка структурного программирования, такими как IF. THEN, WHILE и LOOP.

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

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

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

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

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

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

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

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

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

— предотвращают несанкционированный доступ к объектам схем

— контролируют использование дисков

— контролируют использование системных ресурсов (таких как время процессора)

— осуществляют аудит действий пользователя

Защита базы данных может быть классифицирована по двум различным категориям: защита системы и защита данных. ЗАЩИТА СИСТЕМЫ включает механизмы, контролирующие доступ к базе данных и ее использование на уровне системы.

Например, защита системы включает:

— действительные комбинации имен пользователей и паролей;

— уполномочен ли пользователь присоединяться к базе данных ;

— объем дисковой памяти, доступный объектам пользователя ;

— лимиты ресурсов для пользователя ;

— активность или неактивность аудита базы данных ;

-какие системные операции разрешено выполнять пользователю .

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

Например, защита данных включает:

— какие пользователи имеют доступ к конкретному объекту схемы и какие типы действий разрешены каждому пользователю на этом объекте (например, пользователь SCOTT может выдавать для таблицы EMP предложения SELECT и INSERT, но не предложения DELETE) ;

— какие действия подлежат аудиторскому отслеживанию для каждого объекта схемы.

ORACLE управляет защитой базы данных, используя несколько различных средств, среди которых:

Введение в Oracle

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

Для студентов, изучающих системы управления базами данных Oracle.

ОГЛАВЛЕНИЕ
Глава 1. Основные понятия
1.1. Установка Oracle
1.2. Физическая организация данных
1.3. Логическая организация данных
1.4. Конкурентный доступ к данным
Глава 2. SQL. Определение данных
2.1. Типы данных Oracle
2.2. Правила целостности
2.3. Таблицы
2.4. Прочие объекты
2.5. Объектные привилегии
2.6. Зависимости между объектами
Глава 3. SQL. Выборка данных
3.1. Оператор выборки
3.2. Соединение таблиц
3.3. Множественные операции, группировка, сортировка
Глава 4. SQL. Изменение данных
4.1. Вставка данных
4.2. Обновление данных
4.3. Удаление данных
Глава 5. Процедурное расширение SQL — PL/SQL
5.1. Общие положения
5.2. Типы данных PL/SQL
5.3. Операторы PL/SQL
5.4. Анонимные блоки PL/SQL
5.5. Хранимые процедуры
5.6. Пакеты
5.7. Управление транзакциями
Глава 6. Триггеры
6.1. Создание триггеров
6.2. Выполнение триггеров
6.3. Особенности кода триггеров
Глава 7. Оптимизация запросов
7.1. Оптимизатор
7.2. Инструкции оптимизатора

Технология Oracle

Методическую основу технологических средств программного обеспечения корпорации Oracle (www.oracle.com) составляет метод Oracle (Oracle Method) — комплекс методов, охватывающий большинство процессов жизненного цикла программного обеспечения. В состав комплекса входят:

CDM (Custom Development Method) — разработка прикладного программного обеспечения;

PJM (Project Management Method) — управление проектом;

AIM (Application Implementation Method) — внедрение прикладного программного обеспечения;

BPR (Business Process Reengineering) — реинжиниринг бизнес-процессов;

OCM (Organizational Change Management) — управление изменениями, и др.

Метод CDM оформлен в виде консалтингового продукта CDM Advantage — библиотеки стандартов и руководств (включающего также PJM). Он представляет собой развитие достаточно давно созданного Oracle CASE-Method, известного по использованию CASE-средств фирмы Oracle и книгам Р. Баркера. CDM является методическим руководством по разработке прикладного программного обеспечения с использованием инструментального комплекса Oracle Developer Suite, а сам процесс проектирования и разработки тесно связан с Oracle Designer и Oracle Forms.

В соответствии с CDM жизненный цикл программного обеспечения формируется из определенных этапов (фаз) проекта и процессов, каждый из которых выполняется в течение нескольких этапов (Приложение Б):

стратегия (определение требований);

анализ (формулирование детальных требований к системе);

проектирование (преобразование требований в детальные спецификации системы);

реализация (написание и тестирование приложений);

внедрение (установка новой прикладной системы, подготовка к началу эксплуатации);

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

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

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

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

Процессы CDM выполняют следующие действия:

определение бизнес-требований, или постановка задачи (Business Requirements Definition);

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

определение технической архитектуры (Technical Architecture);

проектирование и реализация базы данных (Database Design and Build). Процесс предусматривает проектирование и реализацию реляционной базы данных, включая создание индексов и других объектов БД;

проектирование и реализация модулей (Module Design and Build). Этот процесс является основным в проекте. Он включает непосредственное проектирование приложения и создание кода прикладной программы;

конвертирование данных (Data Conversion). Цель этого процесса — преобразовывать, перенести и проверить согласованность и непротиворечивость данных, оставшихся в наследство от «старой» системы и необходимых для работы в новой системе;

внедрение, или переход к новой системе (Transition). Этот процесс включает решение задач установки, ввода новой системы в эксплуатацию, прекращения эксплуатации старых систем;

поддержка и сопровождение (Post-System Support).

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


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

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

В соответствии с этими факторами в CDM выделяются два основных подхода к разработке:

Классический подход (Classic). Этапы данного подхода представлены. (Приложение Б) Классический подход применяется для наиболее сложных и масштабных проектов, он предусматривает последовательный и детерминированный порядок выполнения задач. Для таких проектов характерно большое количество реализуемых бизнес-правил, распределенная архитектура, критичность приложения. Применение классического подхода также рекомендуется при нехватке опыта у разработчиков, неподготовленности пользователей, нечетко определенной задаче. Продолжительность таких проектов от 8 до 36 месяцев.

Подход быстрой разработки (Fast Track). Данный подход, в отличие от каскадного классического, является итерационным и основан на методе DSDM (Dynamic Systems Development Method). В этом подходе четыре этапа — стратегия, моделирование требований, проектирование и генерация системы и внедрение в эксплуатацию. Подход используется для реализации небольших и средних проектов с несложной архитектурой системы, гибкими сроками и четкой постановкой задач. Продолжительность проекта от 4 до 16 месяцев.

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

Управление проектом и предоставление отчетности (Control and Reporting). Этот процесс содержит задачи, в результате решения которых определяются границы проекта и подход к разработке, происходит управление изменениями и контролируется возможный риск;

Управление работой (Work Management). Процесс содержит задачи, помогающие контролировать работы, выполняемые в проекте;

Управление ресурсами (Resource Management). Здесь решаются задачи, связанные с обеспечением каждого этапа исполнителями;

Управление качеством (Quality Management). Процесс управления качеством гарантирует, что проект отвечает требованиям пользователя в течение всего процесса разработки;

Управление конфигурацией (Configuration Management).

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

По аналогии с CDM, в PJM предусмотрено широкое использование шаблонов разрабатываемых документов.

Комплекс Oracle Developer Suite содержит набор интегрированных средств разработки для быстрого создания приложений. Он включает средства моделирования, программирования на Java, разработки компонентов, бизнес-анализа и составления отчетов. Все эти средства используют общие ресурсы, что позволяет совместно работать над одним проектом группе разработчиков. Oracle Developer Suite интегрирован с Oracle Database и Oracle Application Server, образуя единую платформу для создания и установки приложений.

В Oracle Developer Suite встроена поддержка языка UML для разработки приложений на основе моделей. Модели хранятся в общем репозитории Oracle, который предназначен для поддержки больших коллективов разработчиков.

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

Oracle Designer представляет собой семейство методов и поддерживающих их программных продуктов. Базовый метод Oracle Designer (CDM) — структурный метод проектирования систем, охватывающий полностью все стадии жизненного цикла программного обеспечения. Версия Oracle Designer для объектно-реляционной СУБД Oracle содержит также расширение в виде средств объектного моделирования, базирующихся на стандарте UML.

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

Repository Administrator — средства управления репозиторием (создание и удаление приложений, управление доступом к данным со стороны различных пользователей, экспорт и импорт данных);

Repository Object Navigator — средство доступа к репозиторию, обеспечивающее многооконный объектно-ориентированный интерфейс доступа ко всем элементам репозитория;

Process Modeler — средство анализа и моделирования бизнес-процессов;

Systems Modeler — набор средств построения функциональных и информационных моделей проектируемой системы, включающий средства для построения диаграмм «сущность-связь» (Entity-Relationship Diagrammer), диаграмм функциональных иерархий (Function Hierarchy Diagrammer), диаграмм потоков данных (Data Flow Diagrammer) и средство анализа и модификации связей объектов репозитория различных типов (Matrix Diagrammer);

Systems Designer — набор средств проектирования программного обеспечения, включающий средство построения структуры реляционной базы данных (Data Diagrammer), а также средства построения диаграмм, отображающих взаимодействие с данными, иерархию, структуру и логику приложений, реализуемую хранимыми процедурами на языке PL/SQL (Module Data Diagrammer, Module Structure Diagrammer и Module Logic Navigator);

Server Generator — генератор описаний объектов БД Oracle (таблиц, индексов, ключей, последовательностей и т.д.);

Forms Generator — генератор приложений для Oracle Forms. Генерируемые приложения включают в себя различные экранные формы, средства контроля данных, проверки ограничений целостности и автоматические подсказки;

Repository Reports — генератор стандартных отчетов, интегрированный с Oracle Reports.

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

Курсовая работа: Проектирование информационных систем

1. Предпроектная стадия

1.1 Описание предметной области

1.2 Разработка функциональной модели предметной области

1.3 Построение UML диаграмм в среде Pacestar UML Diagrammer

2. СТАДИЯ ПРОЕКТИРОВАНИЯ

2.1 Выбор программных средств разработки

2.2 Разработка логической модели

2.3 Разработка физической модели

3. РЕАЛИЗАЦИЯ ПРОЕКТА

3.1 Серверная часть

3.2 Клиентская часть

3.3 Реализация запросов

4. ЭКСПЛУАТАЦИЯ И СОПРОВОЖДЕНИЕ ПРОЕКТА

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

Введение

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

Цели курсовой работы:

· применение на практике знаний, полученных в процессе изучения курса «Проектирование ИС»;

· получение практических навыков создания АИС, основанных на БД.

Задачи курсовой работы:

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

· приобретение навыков использования CASE-систем проектирования ИС;

· развитие самостоятельности при разработке ИС на базе программных продуктов AllFusion Process Modeler r7, AllFusion Data Modeler r7 и СУБД SQL Server 2005.

Курсовая работа состоит из следующих частей:

· Построение функциональной модели предметной области в программной среде AllFusion Process Modeler r7, что включает в себя 3 вида диаграмм:

o диаграммы IDEF0;

o диаграмма DFD;

o диаграмма IDEF3.

· Построение UML диаграмм в среде Pacestar UML diagrammer;

· Проектирование логической и физической модели данных в программной среде AllFusion Data Modeler r7;

· Разработка клиентского приложения ИС в среде Access с использованием БД, находящихся в СУБД MySQL Server 5.1.

1. ПРЕДПРОЕКТНАЯ СТАДИЯ

1.1 Описание предметной области

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

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

Технологический процесс предприятия заключается в последовательном выполнении шагов на различных стадиях выполнения заказа. Выполнение заказа начинается с правильной подготовки автомобиля или детали к окраске. Сначала автомобиль тщательно и неоднократно моется водой, а после сушиться в специальной камере при температуре 90 0С. Затем с автомобиля снимают все декоративные детали с гальваническим покрытием, резиновые прокладки. Затем кузов разбирается на части для чего снимается капот, крышка багажника, двери и в некоторых случаях крылья. Если деталь деформирована, то ее выправляют и придают ей нужную форму. Затем производится зачистка поверхности от старой краски и ржавчинами путем обработки ее наждачной бумагой и стальными щетками с различного рода растворами. Затем поверхность кузова обезжиривается уайт-спиртом. Проверка качества обезжиривания проводится с помощью фильтровальной бумаги: если на бумаге остаются следы жира или грязи, то поверхность необходимо промыть растворителем еще раз (а возможно, и не раз — пока она не будет полностью обезжирена). Затем поверхность выравнивается с помощью шпатлевки. Толщина слоя шпатлевки не должна превышать 0,3 мм. Время сушки зашпатлеванной поверхности должно выдерживаться в соответствии с техническими условиями на используемую шпатлевку. После высыхания шпатлевки следует загрунтовать зашпатлеванные места. После проведения подготовительных работ приступают к следующему этапу.

Этот этап включает в себя замывку детали, то есть обработку ее крупной шкуркой с водой для удаления неровностей, после чего деталь последний раз грунтуют для лучшего наложения краски и ее фиксации. Затем производят еще одну замывку детали мелкой шкуркой с водой для выравнивания окрашиваемой поверхности и убирания лишних слоев грунтовки, после чего приступают к окрашиванию детали. Окрашивание происходит в два этапа через пульверизатор: первый- нанесение проявочного слоя краски отчетливо проявляющий все дефекты подготовленной поверхности (краска разводится 1 к 4 с растворителем); второй — через 20 минут после нанесения проявочного слоя краски, можно наносить основной, декоративный слой(краска разводится 1 к 3 с растворителем). Оба слоя наносятся быстрыми горизонтальными движениями сверху вниз. В зависимости от пожеланий клиента выполняется аэрография. После нанесения краски автомобиль сушится в сушильной камере при температуре 90 0С 2-3 дня.

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

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

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

· Работники склада расходных материалов

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

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

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

Организационная структура управления предприятием, которая включает состав подразделений, приведена на рис.3.

Рассмотрим каждый участок подробнее. Участок работы с клиентами. Его работа заключается в приеме заказов, работе с клиентами (заказчиками), подбор работ, удовлетворяющих требованиям заказчика.

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

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

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

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

Система сквозного контроля за работой предприятия дает возможность полностью отслеживать технологическую цепочку от поступления автомобиля на участок предварительных работ, до его одобрения на участке контроля качества. Это обеспечивает неизменное качество для конечного потребителя, контролируя качество окраски автомобиля по стандартам и технологиям официально предписанными мировыми автокорпорациями как VAG (Audi, VW, Skoda ), PAG (Ford, Volvo, Porsche) BMV RT (BMV, MINI) GM (Opel, Сhevrolet), Toyota, Daimler-Chrysler специально для выполнения ремонтных кузовных и окрасочных работ.

Контроль и обеспечение высокого качества окраски автомобилей — это целый комплекс мероприятий, включающий в себя контроль производимых работ после обработки детали на предварительном этапе и после ее окрашивания. Также происходит контроль качества сборки окрашенного автомобиля. Сквозной контроль проводится с целью предотвращения реализации некачественных работ, не соответствующих требованиям, установленным нормативными документами по стандартизации (ISO/TS 16949).

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

Основными задачами системы сквозного контроля качества работ являются:


1. разработка, внедрение и поддержание систем менеджментана предприятии;

2. разработка и совершенствование схем контроля качества производимых работ;

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

4. обеспечение фонда нормативных документов;

5. обеспечение бесперебойной работы всех участков;

6. организация подготовки, повышения квалификации и обучения сотрудников предприятия.

На предприятии существует тир участка проведения сквозного контроля: контроль качества предварительной обработки детали к окраске; контроль качества окраски детали; контроль качества всех проделанных работ;

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

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

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

Для обслуживания деятельности данного коммерческого предприятия будет разработана автоматизированная информационная система (АИС), предназначенная для быстрой и качественной обработки, учета и контроля задействованной в данной предметной области информации.

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

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

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

В соответствии с предметной областью система строиться с учетом следующих особенностей:

· Каждый этап работ осуществляется на определенном участке цеха;

· Работы выполняются согласно характеристикам, оговоренным с заказчиком при оформлении заказа;

· Основные виды работ проходят контроль качества для перехода на следующий этап;

· Выполненный фронт работ соответствует определенному заказу;

· Заказ определяет клиента;

· Реализация работ осуществляется согласно данным клиента;

· Ведение БД (запись, чтение, модификация, удаление);

· Обеспечение логической непротиворечивости БД;

· Реализация наиболее часто встречающихся запросов в готовом виде;

· Получение информации об этапах прохождения заказа;

· Получение информации о клиентах и заказах;

· Получение списка расходных материалов: их наименования и количества;

· Получение информации о прохождении заказа стадий контроля;

1.2 Разработка функциональной модели предметной области

Наиболее широко используемой методологией описания бизнес-процессов является стандарт IDEF0. Подход IDEF0 был разработан на основе методологии структурного анализа и проектирования SADT. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с развитием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (BPWin, ProCap, IDEF0/EM Tool и др.) Методология IDEF0 предоставляет аналитику прекрасные возможности для описания бизнеса организации на верхнем уровне с акцентом на управлении процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа: по информации, по управлению, движение материальных ресурсов. Продуманные механизмы декомпозиции модели процесса в IDEF0 позволяют существенно упростить работа аналитика. Следует отметить, что модели в нотации IDEF0 предназначены для описания бизнеса на верхнем уровне. Их основное преимущество состоит в возможности описывать управление процессами организации.

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

В настоящее время для описания бизнес-процессов используется несколько методологий. К числу наиболее распространенных относятся методологии моделирования бизнес-процессов (Business Process Modeling), методологии описания потоков работ (Work Flow Modeling) и методологии описания потоков данных (Data Flow Modeling).

Наиболее широко используемой методологией описания бизнес-процессов является стандарт IDEF0. Подход IDEF0 был разработан на основе методологии структурного анализа и проектирования SADT. С момента разработки стандарт не претерпел существенных изменений. В настоящее время развитие методологии IDEF0 сопряжено с развитием поддерживающих ее инструментов – программных продуктов для моделирования бизнес-процессов (BPWin, ProCap, IDEF0/EM Tool и др.) Методология IDEF0 предоставляет аналитику прекрасные возможности для описания бизнеса организации на верхнем уровне с акцентом на управлении процессами. Нотация позволяет отражать в модели процесса обратные связи различного типа: по информации, по управлению, движение материальных ресурсов. Продуманные механизмы декомпозиции модели процесса в IDEF0 позволяют существенно упростить работа аналитика. Следует отметить, что модели в нотации IDEF0 предназначены для описания бизнеса на верхнем уровне. Их основное преимущество состоит в возможности описывать управление процессами организации.

Второй важнейшей методологией описания процессов является методология IDEF3. Формально эта методология называется Work Flow Modeling, что отражает ее сущность. Стандарт IDEF3 предназначен для описания рабочих процессов или, говоря другими словами, потоков работ. Методология описания IDEF3 очень близка к алгоритмическим методам построения схем процессов стандартными средствами построения блок-схем (построение блок-схемы в MS Word). Основа методологии IDEF3 состоит в построении моделей процессов по принципу последовательно выполняемых во времени работ.

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

Для модели, разработанной в курсовой работе, все виды диаграмм представлены в Приложении 1. Также был произведён стоимостной анализ проекта, результаты которого представлены в Приложении 2. Общая стоимость проекта составила 11 850 руб.

В результате того, что диаграмма IDEF0 была дополнена диаграммами DFD и IDEF3, была получена смешанная диаграмма, которая со всех сторон описывает процесс деятельности предприятия (рис. 1.1).

Рис 1.1. Смешанная диаграмма

1.3 Построение UML диаграмм в среде Pacestar UML Diagrammer

UML (сокр. от англ. Unified Modeling Language — унифицированный язык моделирования) — язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем.

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

UML позволяет разработчикам ПО достигнуть соглашения в графических обозначениях для представления общих понятий (таких как класс, компонент, обобщение (generalization), объединение (aggregation) и поведение) и больше сконцентрироваться на проектировании и архитектуре.

UML позволяет создавать диаграммы, такие как:

1. Диаграмма вариантов использования.

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

1. Диаграмма взаимодействия.

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

2. Кооперативная диаграмма.

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

3. Диаграмма классов.

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

4. Диаграмма состояний.

Диаграмма состояний, State Machine diagram (диаграмма конечного автомата, диаграмма состояний) — диаграмма, на которой представлен конечный автомат с простыми состояниями, переходами и композитными состояниями. Конечный автомат — спецификация последовательности состояний, через которые проходит объект или взаимодействие в ответ на события своей жизни, а также ответные действия объекта на эти события. Конечный автомат прикреплён к исходному элементу (классу, кооперации или методу) и служит для определения поведения его экземпляров.

5. Диаграмма пакетов.

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

6. Диаграмма деятельности.

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

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

7. Диаграмма компонентов.

Это статическая структурная диаграмма, демонстрирует внутреннюю структуру классов и, по возможности, взаимодействие элементов (частей) внутренней структуры класса. Структура ИИС представлена на рис.1.9.

2. СТАДИЯ ПРОЕКТИРОВАНИЯ

2.1 Выбор программных средств разработки

программный разработка приложение access

Оболочка клиента будет разработана при помощи Acess, в связи с его тотальным распространением, так как данный продукт является интегрированным в ОС Windows. Не смотря на все увеличивающийся спрос на ОС написанных на ядре Linux подовляющее большинство пользователей работают на различных версиях операционной системы от компании Microsoft. Серверная часть проекта будет базироваться на СУБД MySQL. MySQL имеет двойное лицензирование. MySQL может распространяться в соответствии с условиями лицензии GPL. Однако по условиям GPL, если какая-либо программа включает исходные коды MySQL, то она тоже должна распространяться по лицензии GPL. Это может расходиться с планами разработчиков, не желающих открывать исходные тексты своих программ. Для таких случаев предусмотрена коммерческая лицензия, которая также обеспечивает качественную сервисную поддержку. MySQL также является кроссплатформенным приложением, данная СУБД удобна в использовании, логична, легка в понимании. MySQL является надежным инструментом для управлениями БД. В данной курсовой работе будет использоваться версия MS SQL Server 2005.

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

1. Процессор: х86-совместимый процессор, желательно класса Intel Celeron IV и выше; частота от 1800 Mhz;

2. Оперативная память – от 512 Мб;

3. Видеоадаптер: любая современная видеокарта, от 64Мб ОЗУ;

4. ОС: Windows: 2000/XP/2003 server x86 .

5. СУБД: MS SQL Server 2005.

6. MS office Access 2003 и выше

2.2 Разработка логической модели

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

В данной предметной сущности выделяются следующие базовые сущности, образующие структуру проектируемой ИС:

· Клиент. Атрибуты клиента – код клиента, ФИО, телефон, адрес;

· Заказ. Атрибуты заказа – код заказа, дата заказа, автомобиль наименование детали, вид работы, цвет, стоимость;

· Материалы. Атрибуты Материалов – код материала, тип материалов, наименование, количество, стоимость, сумма;

· Персонал. Атрибуты персонала — код работника, ФИО, адрес, телефон, должность;

· Этап работы. Атрибуты этапа работы — код этапа работы, наименование этапа, дата начала этапа;

· Контроль. Атрибуты контроля – код контроля, дата контроля;

· Вид контроля. Атрибуты вида контроля – вид контроля, комментарии;

· Оценка. Атрибуты оценки – оценка, комментарии;

· Реализация. Атрибуты реализации – код реализации, дата реализации, стоимость всего заказа;


Рис 2.1. Логическая модель данных

2.3 Разработка физической модели

Физическая модель данных зависит от конкретной СУБД, фактически являясь отображением системного каталога. В физической модели содержится информация обо всех объектах БД. Поскольку стандартов на объекты БД не существует (например, нет стандарта на типы данных), физическая модель зависит от конкретной реализации СУБД. Следовательно, одной и той же логической модели могут соответствовать несколько разных физических моделей. Если в логической модели не имеет значения, какой конкретно тип данных имеет атрибут, то в физической модели важно описать всю информацию о конкретных физических объектах — таблицах, колонках, индексах, процедурах и т.д. Полученная физическая модель для СУБД MS SQL Server 2005представлена на рис.2.2.

Физическая модель генерируется в СУБД MS SQL Server 2005, где создается БД с таблицами и полями, которые не содержат записей.

Рис 2.2. Физическая модель данных

3. РЕАЛИЗАЦИЯ ПРОЕКТА

3.1 Серверная часть

Серверная часть проекта базируется на СУБД SQL Server 2005. SQL Server — система управления реляционными базами данных, разработанная корпорацией Microsoft. Основной используемый язык запросов — Transact-SQL, создан совместно Microsoft и Sybase. Transact-SQL является реализацией стандарта ANSI/ISO по структурированному языку запросов (SQL) с расширениями. Используется для работы с базами данных размером от персональных до крупных баз данных масштаба предприятия.

Для обеспечения доступа к данным Microsoft SQL Server поддерживает Open Database Connectivity (ODBC) — интерфейс взаимодействия приложений с СУБД. Версия SQL Server 2005 обеспечивает возможность подключения пользователей через веб-сервисы, использующие протокол SOAP. Это позволяет клиентским программам, не предназначенным для Windows, кроссплатформенно соединяться с SQL Server. Компания Microsoft также выпустила сертифицированный драйвер JDBC, позволяющий приложениям под управлением Java (таким как BEA и IBM WebSphere) соединяться с Microsoft SQL Server 2000 и 2005.

Для создания серверной части была создана новая база данных Avers. Размер файла данных обозначен в 20 мб, файл лога в 3 мб. Имеется возможность работать сразу нескольким пользователям с таблицами БД. Данная БД совместима только с SQL Server 2005. Все остальные параметры были оставлены по умолчанию.

В следствии использования для клиентской части MS Access 2007, AllFusion ERwin Data Modeler не имел возможности перенести данные в данную версию (ERwin интегрирует данные в MS Access 2000/2002/2003). В результате не было возможности использовать AllFusion ERwin Data Modeler для переноса данных и таблицы. В результате в БД были созданы новые таблицы, идентичные таблицам в AllFusion ERwin Data Modeler.

Для создания таблицы, необходимо открыть раздел «Tables» и вызвать меню «New Table. «. В Microsoft SQL Server получили необходимые таблицы(рис.3.1.1). Ключевые поля полностью соответствуют аналогичным полям в ERwin. Все поля, кроме ключевых, не должны иметь пустых значений.

Рис.3.1.1. Перенесенные таблицы.

Затем между таблицами были обозначены и проведены связи(рис. 3.1.2).

Рис.3.1.2 Диаграмма связей между таблицами.

Для установки и использования этой БД, необходимо скопировать файлы «Avers.mdf» и » Avers_log.ldf» в директорию местонахождения БД в SQL Server. По умолчанию это C:\Program Files\Microsoft SQL Server\MSSQL.1\ MSSQL\Data. Затем необходимо запустить SQL Server, выбрать раздел «Database» и в контекстном меню выбрать пункт «Attach». В появившемся окне необходимо нажать кнопку «Add» и выбрать файл «Avers.mdf» и нажать «Ok» (рис 3.1.3).

Рис.3.1.3 Импорт БД.

3.2 Клиентская часть

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

Клиентская часть получает данные из БД, расположенной на SQL Server, обрабатывая и посылая запросы пользователя. Для этого, в приложение были внесены связанные таблицы ODBC, благодаря которым и происходит взаимодействие двух частей программного средства.Рис

Все таблицы связаны связями типа «один-ко-многим» или «один – к -одному» с обеспечением целостности данных(рис.3.1).

Рис 3.1. Связи между таблицами

При запуске АИС пользователь оказывается в главном меню программы (рис. 3.2).

Рис 3.2. Главное окно программы

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

Рис 3.3. Окно добавления нового клиента

При нажатии на кнопку «Оформить заказ» внизу окна происходит переход на форму внесения данных о новом заказе (рис. 3.4):

Рис 3.3. Ввод нового заказа

В случае, если с системой работает работник цеха, то он может внести данные о этапе работы с заказом нажав на кнопку «Внести данные о этапе» в главном меню программы (рис 3.4)

Рис 3.4. Ввод данных о этапе выполнения заказа

Работник так же может вносить данные об используемых для выполнения заказа на этапах материалах. Для этого необходимо перейти на форму внесения материалов, нажав на кнопку «Оформить материалы» в главном меню, или на кнопку «Внести материалы» с формы заполнения данных о этапе работы (рис.3.5).

Рис 3.5. Ввод данных об используемых материалах

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

Главный технолог предприятия, работая с данным приложением, может вносить данные о результатах сквозного контроля качества выполнения этапов заказа. Для этого в главном меню необходимо нажать кнопку «Внести данные о контроле» после чего откроется форма внесения данных о контроле(рис.3.6).

Рис 3.6. Ввод данных об используемых материалах

При нажатии кнопки «Отчет о контроле» будет открыто окно предварительного просмотра выводимого на печать отчета о прохождении заполненного контроля.(рис.3.7).

Рис 3.7. Отчет о прохождении контроля

Так же главный технолог может вносить данные о реализации заказа, перейдя по кнопке «Реализация» главного меню.(рис3.8).

Рис.3.8. Ввод данных о реализации.

При нажатии кнопки «Отчеты» откроется форма с возможными отчетами (рис.3.9)

Рис 3.9. Форма отчеты

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

3.3 Реализация запросов

В АИС «Аверс» организованны запросы, по результатам которых строятся разнообразные отчеты, часть которых представлена на форме «Отчеты».При реализации запрос обращается к БД, которые хранится на сервере(серверная часть приложения), затем перерабатывает информацию, в результате чего находит удовлетворяющие запросу данные, которые и выводит в отчеты через клиентскую часть приложения.

Запрос «Выполненные заказы» (рис.3.10) находит информацию о всех реализованных заказах. Результат запроса представлен в виде формы, просмотреть которую можно нажав на кнопку «Выполненные заказы» формы «Отчеты»(рис.3.11).

Рис.3.10.Запрос «Выполненные заказы»

Рис.3.11.Форма «Выполненные заказы»

Запрос по оценке контроля (рис.3.12.) ищет все работы, оценка контроля которых соответствует выбранному варианту на форме «Отчеты». После выбора интересующей оценки на данной форме и нажатия кнопки «Отчет по оценки контроля» предоставляется отчет(рис.3.13) с соответствующей информацией.

Рис3.12.Запрос по оценке контроля

Рис.3.13.Отчет по оценке контроля

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

Рис.3.14. Отчет «Материалы для заказа»

Рис.3.15.Отчет «материалы для этапа заказа»

Эти отчеты основаны на запросах материалы для заказа (рис.3.16.) и материалы для этапа заказа (рис.3.17).

Рис.3.16.Запрос «Материалы для заказа»

Рис.3.17.Запрос материалов на этап закзаза

При оформлении и реализации заказа необходимо документальное подтверждение. Для организации отчетов «Оформление заказа» и «Оформление реализации заказа» реализуются соответствующие запросы (рис.3.18-3.19) Для распечатки данных отчетов(рис.3.20-3.21) на форме «Отчеты» необходимо ввести номер заказа, на который необходимо распечатать отчет и нажать на соответствующую кнопку.

Рис3.18.Запрос «Оформление заказа»

Рис.3.19.Запрос «Реализация заказа»

Рис.3.20.Отчет об оформлении заказа

Рис.3.21.Отчет о реализации заказа.

Так же реализован запрос о прохождении стадий контроля определенным заказом (рис.3.22). Интересующий заказ выбирается на форме «Отчеты» и после нажатия на кнопку «Прохождение заказом контроля» будет предоставлен отчет в виде формы (рис.3.23.).

Рис.3.22.Запрос о прохождении стадий контроля

Рис.3.23.Очет о прохождении заказом стадий контроля

В АИС «Аверс» для расчета полной стоимости заказа необходимо определить стоимость используемых для выполнения заказа материалов, для этого устраивается запрос «стоимость материалов» основанные на запросе «материалов для заказа»(рис.3.16), результаты которого находятся в форме (рис3.24.).

Рис.3.24.Стоимость используемых для заказа материалов

4. ЭКСПЛУАТАЦИЯ И СОПРОВОЖДЕНИЕ ПРОЕКТА

АИС «Аверс» имеет элементарный и легкодоступный интерфейс, что упрощает работу с ней.

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

В ходе выполнения курсовой работы были достигнутые поставленные цели, такие как: применение на практике знаний, полученных в процессе изучения курса «Проектирование ИС» и получение практических навыков создания автоматизированных информационных систем (АИС), основанных на БД.

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

1. Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Заботина Н.Н. –Братск: Филиал ГОУВПО «БГУЭП», 2007. – Ч.1 – 146 с.

2. Заботина Н.Н. Проектирование информационных систем: Учебное пособие / Заботина Н.Н. –Братск: Филиал ГОУВПО «БГУЭП», 2007. – Ч.2 – 132 с.

3. Мартин Ф., Кендалл С. UML Основы / Ф.Мартин, С.Кендалл. – СПб.:Символ-Плюс, 2002. – 192 с.

4. Бланшет Ж., Саммерфилд М. Qt 4: программирование GUI на C++ / Ж. Бланшет, М.Саммерфилд. – М.:КУДИЦ-ПРЕСС, 2008. – 736 с.

5. Арлоу Д., Нейштадт И. UML 2 и Унифицированный процесс / Д. Арлоу, И. Нейштадт. – СПб.: Символ-Плюс, 2007. – 624 с.

База данных Oracle Database для начинающих: основы базы данных

Ключом к пониманию архитектуры Oracle являются две основные концепции: базы данных и экземпляров.

Базы данных

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

Информация в базе данных сохраняется в виде таблиц. Реляционные таблицы записываются столбцами и имеют имена. Затем данные сохраняются в виде строк в таблице. Таблицы могут быть связаны друг с другом, и для установления этих связей могут использоваться базы данных. Помимо реляционного формата, в Oracle (точнее, в oracle 8i) поддерживаются такие объектно-ориентированные (ОО) структуры, как абстрактные типы данных и методы. Объекты могут быть связаны с другими объектами и могут содержать другие объекты. С помощью объектных представлений можно создавать объектно-ориентированные интерфейсы для данных, не изменяя сами таблицы.

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


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

Табличное пространство представляет собой логический раздел базы данных. В каждой базе данных имеется хотя бы одно табличное пространство, называемое системным (SYSTEM). Можно создавать другие табличные пространства,- чтобы объединить вместе пользователей или приложения, что позволит упростить управление базой данных и повысить ее производительность. В качестве примеров можно привести табличные пространства USERS для общего использования и UNDO для сегментов отмены (см. ниже). Табличное пространство может принадлежать только одной базе данных.

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

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

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

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

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

Другие файлы Oracle

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

Следующие типы файлов, хотя и имеют отношение к базе данных, не являются файлами данных:

■ Журналы повтора
■ Управляющие файлы
■ Трассировочные файлы и журнал предупреждающих сообщений

Введение в Oracle SQL: Курс Интернет-университета информационных технологий

Регион РФ: Москва

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

Курс рассказывает о диалекте SQL, предлагаемом фирмой Oracle для работы с базами данных своего типа. Рассматриваются конструкции языка, касающиеся работы с моделью предметной области и имеющие технологический характер. Изложение сопровождается практическими примерами. Широко распространенная СУБД Oracle представляет собой классическую реализацию систем на основе SQL. Курс рассказывает об основах диалекта SQL, реализованного этой СУБД. Улучшению понимания способствует ретроспективный взгляд на возникновение тех или иных конструкций языка, а также соотнесение их с реляционной моделью, которой SQL обязан своим появлением, и с элементами стандарта ANSI/ISO, связанного с Oracle SQL взаимно-обратным влиянием. Значительная часть утверждений в курсе проиллюстрирована примерами.

Принципы проектирования и использования многомерных баз данных (на примере Oracle Express Server)

А.А. Сахаров, СУБД #3/1996

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

Введение

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

Следует заметить, что МСУБД не являются изобретением девяностых годов, а сам многомерный подход возник практически одновременно и параллельно с реляционным. Еще в начале семидесятых годов консалтинговой фирмой Management Decision System (позже преобразованной в IRI Software) были реализованы первые версии многомерных инструментальных средств. Позднее эти средства стали известны как IRI Multidimensional DBMS, IRI Express Server и с 1995 г. — Oracle Express Server. И хотя к 1995 г. у фирмы IRI Software было уже более тысячи корпоративных пользователей, и она имела более двадцати представительств в Европе, Азии и Латинской Америке, все же МСУБД долгое время оставались в тени своего «старшего» собрата РСУБД. И только начиная с середины девяностых годов, а точнее с 1993 г., интерес к МСУБД начал приобретать всеобщий характер. Именно в этом году появилась новая программная статья одного из основоположников реляционного подхода Э. Кодда [1], в которой он сформулировал 12 основных требований к средствам реализации OLAP (табл. 1) и произвел анализ некоторых как субъективных, так и вполне объективных недостатков реляционного подхода, затрудняющих его использование в задачах, требующих сложной аналитической обработки данных.

Многомерное представление данных

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

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

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

Производительность практически не должна зависеть от количества Измерений в запросе.

Поддержка архитектуры клиент-сервер

Средства должны работать в архитектуре клиент-сервер.

Равноправность всех измерений

Ни одно из измерений не должно быть базовым, все они должны быть равноправными (симметричными).

Динамическая обработка разреженных матриц

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

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

Средства должны обеспечивать возможность работать более чем одному пользователю.

Поддержка операций на основе различных измерений

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

Простота манипулирования данными

Средства должны иметь максимально удобный, естественный и комфортный пользовательский интерфейс.

Развитые средства представления данных

Средства должны поддерживать различные способы визуализации (представления) данных.

Неограниченное число измерений и уровней агрегации данных

Не должно быть ограничений на число поддерживаемых Измерений.

Таблица 1.
12 правил оценки средств для OLAP.

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

собственно требования, например п.п. 1, 2, 3, 6;

не формализуемые пожелания, например п.п. 10, 11;

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

11 требованиям из 12, но реализованная на основе Unix-станции с терминалами, не является OLAP — п.п. 5. Тем более, что уже есть п. 2 (Прозрачность) и п. 3 (Доступность).

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

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

Данная работа состоит из следующих разделов.

Требования к средствам реализации систем оперативной и аналитической обработки данных (рассматриваются отличия в характере данных и в требованиях к средствам реализации оперативных и аналитических систем).

Многомерная модель данных (излагаются основы концепции многомерного представления данных и определяются ее основные понятия).

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

Процедуры представления и анализа данных (приводятся примеры и рассматриваются некоторые особенности языка манипулирования данными Oracle Express Server).

Загрузка данных (приводятся примеры и рассматриваются вопросы загрузки данных).

Структура семейства программных средств Oracle Express.

Требования к средствам реализации систем оперативной и аналитической обработки данных

При первом знакомстве с многомерным подходом к организации данных достаточно часто возникают два противоречивых вопроса.

Для чего собственно нужны МСУБД и нужно ли тратить время и средства на их освоение и приобретение, если все те же задачи можно решить и средствами традиционных РСУБД?

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

И несмотря на то, что эти вопросы выражают достаточно противоположные точки зрения, ответ на них звучит приблизительно одинаково: «Главное достоинство МСУБД состоит именно в том, что они узко специализированны и область их применения — интерактивная аналитическая обработка агрегированных исторических и прогнозируемых данных».

Агрегированные данные. Пользователя, занимающегося анализом, редко интересуют детализированные данные. Более того, чем выше уровень пользователя (руководителя, управляющего, аналитика), тем выше уровень агрегации данных, используемых им для принятия решения. Рассмотрим в качестве примера фирму по продаже автомобилей. Коммерческого директора такой фирмы мало интересует вопрос: «Какого цвета «Жигули» успешнее всего продает один из ее менеджеров — Петров: белого или красного?» Для него важно, какие модели и какие цвета предпочитают в данном регионе. Его также мало интересует детализация на уровне контракта, часа или даже дня. Например, если выяснится, что «ВАЗ2108 Красного цвета» чаще покупают в утренние часы, этот факт скорее заинтересует психиатра, а не коммерческого аналитика. Для правильного формирования склада ему важна и необходима информация на уровне декады, месяца или даже квартала.

Исторические данные. Важнейшим свойством данных в аналитических задачах является их Исторический характер. После того как зафиксировано, что Петров в июне 1996 г. продал 2 автомобиля «Волга» и 12 автомобилей «Жигули», данные об этом событии становятся историческим (свершившимся) фактом. И после того, как информация об этом факте получена, верифицирована и заведена в БД, она может быть сколько угодно раз считана оттуда, но уже не может и не должна быть изменена. Историчность данных предполагает не только высокий уровень статичности (неизменности) как собственно данных (например: Петров продал в 1995 г. 51 автомобиль «Жигули ВАЗ2105» ), так и их взаимосвязей (например: в 1995 г. Петров работал в Восточном Регионе; в 1995 г. продавались автомобили модели ВАЗ2105 ). А это, в свою очередь, дает возможность использовать специализированные, основанные на предположении о статичности данных и их взаимосвязей методы загрузки, хранения, индексации и выборки.

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

для уменьшения времени обработки запросов желательно, чтобы уже в БД данные хранились (были предварительно отсортированы) в том порядке, в котором они наиболее часто запрашиваются;

так и на языки описания и манипулирования данными, например:

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

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

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

Например, если мы строим прогноз об объеме продаж на июнь 1997 г. для менеджера Петрова, то, по мере поступления фактических (Исторических) данных за 1996 г., эта цифра может и будет многократно изменяться и уточняться. Более того, достаточно часто прогнозирование и моделирование затрагивает не только будущие, еще не произошедшие, но и прошлые, уже свершившиеся события. Например, анализ: «а, что будет (было бы). если (бы). «, строится на предположении о том, что значения некоторых данных, в том числе и из прошлого, отличны от реальных. И для ответа на вопрос:

«Какой был бы Прогноз по объему продаж автомобилей «Волга» для менеджера Петрова на июнь 1997 г., если бы объем продаж «Волг» в июне 1996 г. у него возрос на тот же процент, что объем продаж «Жигулей»?»

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

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

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

менеджер Петров продал еще одни «Жигули ВАЗ2106»;

менеджера Петрова перевели из Восточного филиала фирмы в Западный.

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

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

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

системы, ориентированные на оперативную (транзакционную или операционную) обработку данных;

системы, ориентированные на анализ данных — системы поддержки принятия решений.

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

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

Илон Маск рекомендует:  Сайт внутри exe файла
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL
Название: Проектирование информационных систем
Раздел: Рефераты по информатике, программированию
Тип: курсовая работа Добавлен 23:56:48 03 марта 2011 Похожие работы
Просмотров: 17037 Комментариев: 14 Оценило: 7 человек Средний балл: 4.7 Оценка: 5 Скачать