Главная Коллекция "Revolution" Программирование, компьютеры и кибернетика Особенность проектирования информационной системы

Особенность проектирования информационной системы

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

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

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

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

Страница:

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

  • Оглавление
  • Введение
  • Глава 1. Состав и перспективы развития автоматизированного рабочего места
  • 1.1 Цели проектирования информационной системы
  • 1.2 Подходы к проектированию информационных систем
  • 1.2.1 Прикладные и предметные БД
  • 1.2.2 Структурный и процессный подходы проектирования
  • 1.3 Потребности информационных систем
  • 1.4 Модели организации СУБД
  • 1.5 Функциональная структура объекта автоматизации
  • 1.6 Исследование потоков и структуры информации
  • 1.7 Обследование документов и документооборота системы управления
  • 1.8 Выводы
  • Глава 2. Разработка автоматизированного рабочего места
  • 2.1 Постановка задачи
  • 2.2 Проектирование структуры БД
  • 2.3 Информационно - логическая модель
  • 2.4 Проектирование структуры меню приложений
  • 2.5 Создание приложения в среде Visual FoxPro
  • 2.6 Создание приложения в среде Delphi
  • Глава 3. Исследование эффективности обработки задач
  • 3.1 Краткая характеристика программного обеспечения, используемого при создании СУБД
  • 3.2 Обоснование выбора программной среды разработки приложения
  • 3.3 Преимущества и недостатки разработки приложения в выбранных средах
  • 3.4 Тестирование работы приложений
  • 3.5 Сравнение и анализ объемов полученных приложений
  • 3.6 Занимаемые приложениями ресурсы процессора
  • 3.7 Быстродействие обработки данных
  • 3.8 Выводы
  • Заключение
  • Список литературы
  • Введение
  • Основой для учета, контроля и планирования служат всевозможные картотеки, регистрационные журналы, списки и т.д. Они постепенно накапливаются и обновляются. При большом объеме информации поиск и обобщение необходимых сведений, осуществляемых вручную, представляют собой трудоемкий процесс.
  • С появлением ЭВМ и использованием их для обработки информации появилась возможность автоматизировать решение многих информационно - справочных и расчетных задач.
  • Современные масштабы и темпы внедрения средств автоматизации управления в народном хозяйстве с особой остротой ставит задачу проведения комплексных исследований, связанных с всесторонним изучением и обобщением возникающих при этом проблем как практического, так и теоретического характера.
  • Цель данной работы - разработка программного продукта, приемлемого для отдела кадров нашего факультета, обеспечивающий создание, заполнение и корректировку баз данных, и исследование на его основе эффективности обработки малых задач. Для исследования необходимо создать приложение в двух выбранных программных средах, обосновать выбор и проанализировать полученные результаты: скорость обработки данных, время загрузки приложений, время выполнения операций, объем занимаемой памяти приложениями.
  • Поставленная в работе цель является в настоящее время достаточно актуальной, поскольку объективно существующие условия деятельности "Отдела кадров" привели к известным негативным явлениям: значительные потери информации, трудность оперативного и точного учета кадров.
  • Следует отметить что в настоящее время разработано и выпущено множество функционально полных СУБД, в которых предусмотрены все необходимые средства для определения и обработки данных, а также для управления ими при работе с большими объемами информации. Эти системы управления базами данных предоставляют возможность контролировать задание структуры и описание данных, работу с ними и организацию коллективного пользования этой информацией. Они также существенно увеличивают возможности и облегчают каталогизацию и ведение больших объемов хранящейся в многочисленных таблицах информации.
  • Параллельно с разработкой СУБД многие фирмы разрабатывают программные комплексы визуального программирования, обладающие универсальностью. Эти пакеты позволяют разрабатывать приложения любых направлений. Вложена в них и возможность разработки СУБД.
  • Таким образом, на сегодняшний день разработчик не связан рамками какого-либо конкретного пакета, а в зависимости от поставленной задачи может использовать самые разные программные среды. Поэтому, более важным представляется необходимость сравнения приложений созданных при помощи специализированных пакетов разработки СУБД и универсальных средств разработки приложений.
  • Задачи данной работы:
  • 1. Изучить соответствующий теоретический материал по данной теме.
  • 2. Предварительно изучить предметную область, выделить задачи и документы, которые требуют процесса автоматизации.
  • 3. Разработать программную оболочку (интерфейс) в двух выбранных средах.
  • 4. Написать программу в двух средах, которая бы обеспечивала учет сотрудников и студентов Рыбницкого филиала ПТУ им. Т. Г. Шевченко, получение различных документов (приказов), получение основных статистических данных и диаграмм.
  • 5. Исследовать возможность построения готового приложения для конечного пользователя в принципиально разных и одновременно, функционально схожих средах. Для исследования выбраны Visual FoxPro и Delphi, где Visual FoxPro - это специализированная среда разработки СУБД, a Delphi - универсальная среда разработки программных продуктов разной направленности.
  • Дипломный проект состоит из трех глав, со следующим содержанием:
  • В главе 1, на основе анализа литературы дано теоретическое обоснование разработки проекта «Автоматизация работы специалиста отдела кадров Рыбницкого филиала ПГУ им. Т. Г. Шевченко», дается ответ на вопрос: «Что такое автоматизированное рабочее место, для чего оно нужно?». В ней также дано описание основных структурных элементов автоматизированного рабочего места.
  • В главе 2 приводится обоснование разработки автоматизированного рабочего места в программных средах Visual FoxPro и Delphi в целях исследования эффективности обработки задач на примере автоматизации работы специалиста отдела кадров. В главе также рассматривается проектирование структуры БД и построение ее информационно - логической модели.
  • Глава 3 посвящена исследование эффективности обработки малых задач каждым приложением. В главе также проводится анализ основных результатов исследования, на основе чего делаются выводы и даются соответствующие рекомендации.
  • Глава 1. Состав и перспективы развития автоматизированного рабочего места
  • 1.1 Цели проектирования информационной системы
  • С самого начала развития вычислительной техники образовались два основных направления ее использования. Первое направление - применение вычислительной техники для выполнения численных расчетов, которые слишком долго или вообще невозможно производить вручную. Становление этого направления способствовало интенсификации методов численного решения сложных математических задач, развитию класса языков программирования, ориентированных на удобную запись численных алгоритмов, становлению обратной связи с разработчиками новых архитектур ЭВМ.
  • Второе направление, это использование средств вычислительной техники в автоматических или автоматизированных информационных системах. В самом широком смысле информационная система представляет собой программный комплекс, функции которого состоят в поддержке надежного хранения информации в памяти компьютера, выполнении специфических для данного приложения преобразований информации и/или вычислений, предоставлении пользователям удобного и легко осваиваемого интерфейса. Обычно объемы информации, с которыми приходится иметь дело таким системам, достаточно велики, а сама информация имеет достаточно сложную структуру. Классическими примерами информационных систем являются банковские системы, системы резервирования авиационных или железнодорожных билетов, мест в гостиницах и т.д.
  • При проектировании информационной системы необходимо провести анализ целей этой системы и выявить требования к ней отдельных пользователей (сотрудников организации). Сбор данных начинается с изучения сущностей организации и процессов, использующих эти сущности (подробнее в приложении Б). Сущности группируются по "сходству" (частоте их использования для выполнения тех или иных действий) и по количеству ассоциативных связей между ними (самолет - пассажир, преподаватель - дисциплина, студент - сессия и т.д.). Сущности или группы сущностей, обладающие наибольшим сходством и (или) с наибольшей частотой ассоциативных связей объединяются в предметные БД. (Нередко сущности объединяются в предметные БД без использования формальных методик - по "здравому смыслу".) Для проектирования и ведения каждой предметной БД (нескольких БД) назначается АБД, который далее занимается детальным проектированием базы.
  • Основная цель проектирования БД - это сокращение избыточности хранимых данных, а следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте. Так называемый, "чистый" проект БД ("Каждый факт в одном месте") можно создать, используя методологию нормализации отношений.
  • 1.2 Подходы к проектированию информационных систем
  • 1.2.1 Прикладные и предметные БД
  • Только небольшие организации могут обобществить данные в одной полностью интегрированной базе данных. Чаще всего администратор баз данных (даже если это группа лиц) практически не в состоянии охватить и осмыслить все информационные требования сотрудников организации (т.е. будущих пользователей системы). Поэтому информационные системы больших организаций содержат несколько десятков БД, нередко распределенных между несколькими взаимосвязанными ЭВМ различных подразделений.
  • Отдельные БД могут объединять все данные, необходимые для решения одной или нескольких прикладных задач, или данные, относящиеся к какой-либо предметной области (например, финансам, студентам, преподавателям, кулинарии и т.п.). Первые обычно называют прикладными БД, а вторые - предметными БД (соотносящимся с предметами организации, а не с ее информационными приложениями).
  • Предметные БД позволяют обеспечить поддержку любых текущих и будущих приложений, поскольку набор их элементов данных включает в себя наборы элементов данных прикладных БД. Вследствие этого предметные БД создают основу для обработки неформализованных, изменяющихся и неизвестных запросов и приложений (приложений, для которых невозможно заранее определить требования к данным). Такая гибкость и приспосабливаемость позволяет создавать на основе предметных БД достаточно стабильные информационные системы, т.е. системы, в которых большинство изменений можно осуществить без вынужденного переписывания старых приложений.
  • Основывая же проектирование БД на текущих и предвидимых приложениях, можно существенно ускорить создание высокоэффективной информационной системы, т.е. системы, структура которой учитывает наиболее часто встречающиеся пути доступа к данным. Поэтому прикладное проектирование до сих пор привлекает некоторых разработчиков. Однако по мере роста числа приложений таких информационных систем быстро увеличивается число прикладных БД, резко возрастает уровень дублирования данных и повышается стоимость их ведения.
  • Таким образом, каждый из рассмотренных подходов к проектированию воздействует на результаты проектирования в разных направлениях. Желание достичь и гибкости, и эффективности привело к формированию методологии проектирования, использующей как предметный, так и прикладной подходы. В общем случае предметный подход используется для построения первоначальной информационной структуры, а прикладной - для ее совершенствования с целью повышения эффективности обработки данных.
  • 1.2.2 Структурный и процессный подходы проектирования
  • Первый подход основан на использовании организационной структуры компании, когда проектирование системы идет по структурным подразделениям. Технологии деятельности в этом случае описываются через технологии работы структурных подразделений, а взаимодействие структурных подразделений -- через модель верхнего уровня. Если компания представляет собой сложную структуру типа холдинга, или предприятие-сеть, то необходимо также иметь модель взаимодействия всех входящих в него элементов, в которой будут отражены не только технологические, но также финансовые и юридические моменты.
  • Главным недостатком структурного подхода является привязка к организационной структуре, которая очень быстро меняется, поэтому в Системный проект информационной системы приходится часто вносить изменения.
  • Несколько по-иному обстоит дело при процессном подходе. Этот подход ориентирован не на организационную структуру, а на процессы. Однако процессный подход подводит к необходимости перехода на так называемое тощее производство или тощую ресурсосберегающую организационную структуру (Lean production).
  • Технологии работы, в случае процессного подхода определяются характером деятельности Организации и существуют независимо от ее организационно-штатной структуры. Каждая технология работы состоит из последовательно и параллельно выполняющихся функций, которые могут различным образом конфигурироваться под любого исполнителя и любое должностное лицо посредством механизма полномочий. Полномочия регулируют доступ пользователей к прикладным задачам, к информации базы данных и к обобщенным данным, характеризующим состояния процессов деятельности Организации.
  • Прикладная задача представляет собой программный модуль, поддерживающий некий логически законченный процесс, направленный на учет данных и облегчение выполнения пользователями их обязанностей в рамках технологии работы. Любая технология работы Организации включает несколько прикладных задач, логически увязанных между собой путем использования в каждой следующей прикладной задаче результатов задач предыдущих, хранящихся в базе данных.
  • Процессный подход к анализу и моделированию бизнес-процессов, а также к последующей разработке требований к информационным системам позволяет оперативно сопровождать (изменять и дорабатывать) описанные рациональные технологии работ, безболезненно (параллельно с эксплуатацией) для пользователей модернизировать информационную систему Компании, наращивать мощность базы данных и поддерживать ее в актуальном состоянии.
  • 1.3 Потребности информационных систем
  • Информационные системы главным образом ориентированы на хранение, выбор и модификацию постоянно существующей информации. Структура информации зачастую очень сложна, и хотя структуры данных различны в разных информационных системах, между ними часто бывает много общего. На начальном этапе использования вычислительной техники для управления информацией проблемы структуризации данных решались индивидуально в каждой информационной системе. Производились необходимые надстройки над файловыми системами (библиотеки программ), подобно тому, как это делается в компиляторах, редакторах и т.д.
  • Но поскольку информационные системы требуют сложных структур данных, эти дополнительные индивидуальные средства управления данными являлись существенной частью информационных систем и практически повторялись от одной системы к другой. Стремление выделить и обобщить общую часть информационных систем, ответственную за управление сложно структурированными данными, явилось, на наш взгляд, первой побудительной причиной создания СУБД. Очень скоро стало понятно, что невозможно обойтись общей библиотекой программ, реализующей над стандартной базовой файловой системой более сложные методы хранения данных.
  • Покажем это на примере. Предположим, что мы хотим реализовать простую информационную систему, поддерживающую учет сотрудников. Система должна выполнять следующие действия: выдавать списки сотрудников по отделам, поддерживать возможность перевода сотрудника из одного отдела в другой, приема на работу новых сотрудников и увольнения работающих. Для каждого отдела должна поддерживаться возможность получения имени руководителя этого отдела, общей численности отдела, общей суммы выплаченной в последний раз зарплаты и т.д. Для каждого сотрудника должна поддерживаться возможность выдачи номера удостоверения по полному имени сотрудника, выдачи полного имени по номеру удостоверения, получения информации о текущем соответствии занимаемой должности сотрудника и о размере его зарплаты.
  • Предположим, что мы решили основывать эту информационную систему на файловой системе и пользоваться при этом одним файлом, расширив базовые возможности файловой системы за счет специальной библиотеки функций. Но вскоре мы увидим, что даже для такой простой системы ее реализация на базе файловой системы, во-первых, требует создания достаточно сложной надстройки для многоключевого доступа к файлам, и, во-вторых, вызывает требование существенной избыточности хранения (для каждого сотрудника одного отдела повторяется имя руководителя) и выполнение массовой выборки и вычислений для получения суммарной информации об отделах.
  • Но это еще не все, что обычно требуют от СУБД. Во-первых, даже в нашем примере неудобно реализовывать такие запросы как "выдать общую численность отдела, в котором работает Петр Иванович Сидоров". Было бы гораздо проще, если бы СУБД позволяла сформулировать такой запрос на близком пользователям языке. Такие языки называются языками запросов к базам данных. Таким образом, при формулировании запроса СУБД позволит не задумываться о том, как будет выполняться этот запрос.
  • Наконец, представим себе, что мы хотим обеспечить параллельную (например, многотерминальную) работу с базой данных сотрудников. Если опираться только на использование файлов, то для обеспечения корректности на все время модификации любого из двух файлов доступ других пользователей к этому файлу будет блокирован (вспомните возможности файловых систем для синхронизации параллельного доступа). Таким образом, зачисление на работу Петра Ивановича Сидорова существенно затормозит получение информации о сотруднике Иване Сидоровиче Петрове, даже если они будут работать в разных отделах. Настоящие СУБД обеспечивают гораздо более тонкую синхронизацию параллельного доступа к данным.
  • Понятие согласованности данных является ключевым понятием баз данных. Фактически, если информационная система (даже такая простая, как в нашем примере) поддерживает согласованное хранение информации в нескольких файлах, можно говорить о том, что она поддерживает базу данных. Если же некоторая вспомогательная система управления данными позволяет работать с несколькими файлами, обеспечивая их согласованность, можно назвать ее системой управления базами данных. Уже только требование поддержания согласованности данных в нескольких файлах не позволяет обойтись библиотекой функций: такая система должна иметь некоторые собственные данные (метаданные) и даже знания, определяющие целостность данных.
  • Таким образом, СУБД решают множество проблем, которые затруднительно или вообще невозможно решить при использовании файловых систем.
  • 1.4 Модели организации СУБД
  • Сложность современной технологии баз данных явилась результатом развития в течении нескольких десятилетий способов обработки данных и управления информацией. Подталкиваемая, с одной стороны, нуждами и требованиями менеджмента и ограниченная, с другой стороны, возможностями технологии, обработка данных развивалась от примитивных методов пятидесятых годов к сложным интегрированным системам сегодняшнего дня. В настоящее время процесс создания максимально мощных систем управления базами данных идет полным ходом. За несколько десятилетий последовательно появились системы, основанные на трех базовых моделях данных. Перечислим эти три модели: дореляционные, реляционные и постреляционные.
  • Начнем с некоторых наиболее общих характеристик ранних(дореляционных) систем:
  • a. Эти системы активно использовались в течение многих лет, дольше, чем используется какая-либо из реляционных СУБД. На самом деле некоторые из ранних систем используются даже в наше время, накоплены громадные базы данных, и одной из актуальных проблем информационных систем является использование этих систем совместно с современными системами.
  • b. Все ранние системы не основывались на каких-либо абстрактных моделях. Как мы упоминали, понятие модели данных фактически вошло в обиход специалистов в области БД только вместе с реляционным подходом. Абстрактные представления ранних систем появились позже на основе анализа и выявления общих признаков у различных конкретных систем.
  • c. В ранних системах доступ к БД производился на уровне записей. Пользователи этих систем осуществляли явную навигацию в БД, используя языки программирования, расширенные функциями СУБД. Интерактивный доступ к БД поддерживался только путем создания соответствующих прикладных программ с собственным интерфейсом.
  • d. Можно считать, что уровень средств ранних СУБД соотносится с уровнем файловых систем примерно так же, как уровень языка Кобол соотносится с уровнем языка Ассемблера. Заметим, что при таком взгляде уровень реляционных систем соответствует уровню языков Ада или APL.
  • e. Навигационная природа ранних систем и доступ к данным на уровне записей заставляли пользователя самого производить всю оптимизацию доступа к БД, без какой-либо поддержки системы.
  • f. После появления реляционных систем большинство ранних систем было оснащено "реляционными" интерфейсами. Однако в большинстве случаев это не сделало их по-настоящему реляционными системами, поскольку оставалась возможность манипулировать данными в естественном для них режиме.
  • Сильные места ранних СУБД:
  • · Развитые средства управления данными во внешней памяти на низком уровне;
  • · Возможность построения вручную эффективных прикладных систем;
  • · Возможность экономии памяти за счет разделения подобъектов (в сетевых системах).
  • Недостатки:
  • · Слишком сложно пользоваться;
  • · Фактически необходимы знания о физической организации;
  • · Прикладные системы зависят от этой организации;
  • · Их логика перегружена деталями организации доступа к БД.
  • Реляционные базы данных и системы управления реляционными базами данных являются наиболее распространенными в настоящее время, хотя наряду с общепризнанными достоинствами обладают и рядом недостатков. В настоящее время основным предметом критики постреляционных систем является не их недостаточная эффективность, а присущая этим системам некоторая ограниченность (прямое следствие простоты) при использовании в нетрадиционных областях, в которых требуются предельно сложные структуры данных. Другим, часто отмечаемым недостатком реляционных баз данных, является невозможность адекватного отражения семантики предметной области. Поэтому современные исследования в области постреляционных систем, главным образом, посвящены устранению именно этих недостатков, и во многом требования к этим системам означают просто необходимость реализации свойств, отсутствующих в большинстве текущих реляционных СУБД. В их число, например, входит полнота системы типов, поддержка иерархии и наследования типов, возможность управления сложными объектами и т.д. Таким образом постреляционные системы, сохраняя основные свойства реяционных СУБД, в то же время имеют свои, отличные от других, возможности.
  • Так, например СУБД POSTGRES поддерживает темпоральную модель хранения и доступа к данным. То есть для любого объекта данных, созданного в момент времени t1 и уничтоженного в момент времени t2, в БД сохраняются (и доступны пользователям) все его состояния во временном интервале (t1,t2). Обычные же БД хранят мгновенный снимок модели предметной области, и любое изменение в момент времени t некоторого объекта приводит к недоступности этого объекта в предыдущий момент времени. Хотя, на самом деле, в большинстве развитых СУБД предыдущее состояние объекта сохраняется в журнале изменений, но осуществления доступа со стороны пользователя нет.
  • Рассмотрим основные направления исследований и разработок в области так называемых постреляционных систем, т.е. систем, относящихся к следующему поколению (хотя термин "next-generation DBMS" зарезервирован для некоторого подкласса современных систем).
  • Хотя отнесение СУБД к тому или иному классу в настоящее время может быть выполнено только условно (например, иногда объектно-ориентированную СУБД O2 относят к системам следующего поколения), можно отметить три направления в области СУБД следующего поколения. Чтобы не изобретать названий, будем обозначать их именами наиболее характерных СУБД.
  • 1. Направление Postgres. Основная характеристика: максимальное следование (насколько это возможно с учетом новых требований) известным принципам организации СУБД (если не считать коренной переделки системы управления внешней памятью).
  • 2. Направление Exodus/Genesis. Основная характеристика: создание собственно не системы, а генератора систем, наиболее полно соответствующих потребностям приложений. Решение достигается путем создания наборов модулей со стандартизованными интерфейсами, причем идея распространяется вплоть до самых базисовых слоев системы.
  • 3. Направление Starburst. Основная характеристика: достижение расширяемости системы и ее приспосабливаемости к нуждам конкретных приложений путем использования стандартного механизма управления правилами. По сути дела, система представляет собой некоторый интерпретатор системы правил и набор модулей-действий, вызываемых в соответствии с этими правилами. Можно изменять наборы правил (существует специальный язык задания правил) или изменять действия, подставляя другие модули с тем же интерфейсом.
  • В целом можно сказать, что СУБД следующего поколения - это прямые наследники реляционных систем. Тем не менее, различные направления систем третьего поколения стоит рассмотреть отдельно, поскольку они обладают некоторыми разными характеристиками.
  • Развитие объектно-ориентированного программирования привело к разработке объектно-ориентированных СУБД. Направление объектно-ориентированных баз данных (ООБД) возникло сравнительно давно. Публикации появлялись уже в середине 1980-х. Однако наиболее активно это направление развивается в последние годы. С каждым годом увеличивается число публикаций и реализованных коммерческих и экспериментальных систем.
  • Возникновение направления ООБД определяется прежде всего потребностями практики: необходимостью разработки сложных информационных прикладных систем, для которых технология предшествующих систем БД не была вполне удовлетворительной.
  • Конечно, ООБД возникли не на пустом месте. Соответствующий базис обеспечивают как предыдущие работы в области БД, так и давно развивающиеся направления языков программирования с абстрактными типами данных и объектно-ориентированных языков программирования.
  • Что касается связи с предыдущими работами в области БД, то наиболее сильное влияние на работы в области ООБД оказывают проработки реляционных СУБД и следующее хронологически за ними семейство БД, в которых поддерживается управление сложными объектами. Кроме того, исключительное влияние на идеи и концепции ООБД и, как кажется, всего объектно-ориентированного подхода оказал подход к семантическому моделированию данных. Достаточное влияние оказывают также развивающиеся параллельно с ООБД направления дедуктивных и активных БД.
  • Среди языков и систем программирования наибольшее первичное влияние на ООБД оказал Smalltalk. Этот язык сам по себе не является полностью пионерским, хотя в нем была введена новая терминология, являющаяся теперь наиболее распространенной в объектно-ориентированном программировании. На самом деле, Smalltalk основан на ряде ранее выдвинутых концепций.
  • Большое число опубликованных работ не означает, что все проблемы ООБД полностью решены. Как отмечается в Манифесте группы ведущих ученых, занимающихся ООБД, современная ситуация с ООБД напоминает ситуацию с реляционными системами середины 1970-х. При наличии большого количества экспериментальных проектов (и даже коммерческих систем) отсутствует общепринятая объектно-ориентированная модель данных, и не потому, что нет ни одной разработанной полной модели, а по причине отсутствия общего согласия о принятии какой-либо модели. На самом деле имеются и более конкретные проблемы, связанные с разработкой декларативных языков запросов, выполнением и оптимизацией запросов, формулированием и поддержанием ограничений целостности, синхронизацией доступа и управлением транзакциями и т.д.
  • В наиболее общей и классической постановке объектно-ориентированный подход базируется на следующих концепциях:
  • * объекта и идентификатора объекта;
  • * атрибутов и методов;
  • * классов;
  • * иерархии и наследования классов.
  • Любая сущность реального мира в объектно-ориентированных языках и системах моделируется в виде объекта. Любой объект при своем создании получает генерируемый системой уникальный идентификатор, который связан с объектом все время его существования и не меняется при изменении состояния объекта.
  • Каждый объект имеет состояние и поведение. Состояние объекта - набор значений его атрибутов. Поведение объекта - набор методов (программный код), оперирующих над состоянием объекта. Значение атрибута объекта - это тоже некоторый объект или множество объектов. Состояние и поведение объекта инкапсулированы в объекте; взаимодействие объектов производится на основе передачи сообщений и выполнении соответствующих методов.
  • Множество объектов с одним и тем же набором атрибутов и методов образует класс объектов. Объект должен принадлежать только одному классу (если не учитывать возможности наследования). Допускается наличие примитивных предопределенных классов, объекты-экземпляры которых не имеют атрибутов: целые, строки и т.д. Класс, объекты которого могут служить значениями атрибута объектов другого класса, называется доменом этого атрибута.
  • Допускается порождение нового класса на основе уже существующего класса - наследование. В этом случае новый класс, называемый подклассом существующего класса (суперкласса), наследует все атрибуты и методы суперкласса. В подклассе, кроме того, могут быть определены дополнительные атрибуты и методы. Различаются случаи простого и множественного наследования. В первом случае подкласс может определяться только на основе одного суперкласса, во втором случае суперклассов может быть несколько. Если в языке или системе поддерживается единичное наследование классов, набор классов образует древовидную иерархию. При поддержании множественного наследования классы связаны в ориентированный граф с корнем, называемый решеткой классов. Объект подкласса считается принадлежащим любому суперклассу этого класса.
  • Одной из более поздних идей объектно-ориентированного подхода является идея возможного переопределения атрибутов и методов суперкласса в подклассе (перегрузки методов). Эта возможность увеличивает гибкость, но порождает дополнительную проблему: при компиляции объектно-ориентированной программы могут быть неизвестны структура и программный код методов объекта, хотя его класс (в общем случае - суперкласс) известен. Для разрешения этой проблемы применяется так называемый метод позднего связывания, означающий, по сути дела, интерпретационный режим выполнения программы с распознаванием деталей реализации объекта во время выполнения посылки сообщения к нему. Введение некоторых ограничений на способ определения подклассов позволяет добиться эффективной реализации без потребностей в интерпретации.
  • Как видно, при таком наборе базовых понятий, если не принимать во внимание возможности наследования классов и соответствующие проблемы, объектно-ориентированный подход очень близок к подходу языков программирования с абстрактными (или произвольными) типами данных.
  • С другой стороны, если абстрагироваться от поведенческого аспекта объектов, объектно-ориентированный подход весьма близок к подходу семантического моделирования данных (даже и по терминологии). Фундаментальные абстракции, лежащие в основе семантических моделей, неявно используются и в объектно-ориентированном подходе. На абстракции агрегации основывается построение сложных объектов, значениями атрибутов которых могут быть другие объекты. Абстракция группирования - основа формирования классов объектов. На абстракциях специализации/обобщения основано построение иерархии или решетки классов.
  • Видимо, наиболее важным новым качеством ООБД, которого позволяет достичь объектно-ориентированный подход, является поведенческий аспект объектов. В прикладных информационных системах, основывавшихся на БД с традиционной организацией (вплоть до тех, которые базировались на семантических моделях данных), существовал принципиальный разрыв между структурной и поведенческой частями. Структурная часть системы поддерживалась всем аппаратом БД, ее можно было моделировать, верифицировать и т.д., а поведенческая часть создавалась изолированно. В частности, отсутствовали формальный аппарат и системная поддержка совместного моделирования и гарантирования согласованности этих структурной (статической) и поведенческой (динамической) частей. В среде ООБД проектирование, разработка и сопровождение прикладной системы становится процессом, в котором интегрируются структурный и поведенческий аспекты. Конечно, для этого нужны специальные языки, позволяющие определять объекты и создавать на их основе прикладную систему.
  • Специфика применения объектно-ориентированного подхода для организации и управления БД потребовала уточненного толкования классических концепций и некоторого их расширения. Это определяется потребностями долговременного хранения объектов во внешней памяти, ассоциативного доступа к объектам, обеспечения согласованного состояния ООБД в условиях мультидоступа и тому подобных возможностей, свойственных базам данных. Выделяются три аспекта, отсутствующие в традиционной парадигме, но требующиеся в ООБД.
  • Первый аспект касается потребности в средствах спецификации знаний при определении класса (ограничений целостности, правил дедукции и т.п.). Второй аспект - потребность в механизме определения разного рода семантических связей между объектами вообще говоря разных классов. Фактически это означает требование полного распространения на ООБД средств семантического моделирования данных. Потребность в использовании абстракции ассоциирования отмечается и в связи с использовании ООБД в сфере автоматизированного проектирования и инженерии. Наконец, третий аспект связан с пересмотром понятия класса. В контексте ООБД оказывается более удобным рассматривать класс как множество объектов данного типа, т.е. одновременно поддерживать понятия и типа и класса объектов.
  • В настоящее время ведется очень много экспериментальных и производственных работ в области объектно-ориентированных СУБД. Больше всего университетских работ, которые в основном носят исследовательский характер. Но уже несколько лет назад отмечалось существование по меньшей мере тринадцати коммерчески доступных систем ООБД. Среди них системы O2, ORION, GemStone и Iris.
  • Описание особенностей двух объектно-ориентированных СУБД показывает прагматичность современного подхода к организации таких систем. Их разработчики не стремятся к полному соблюдению чистоты объектно-ориентированного подхода и применяют наиболее простые решения проблем. Пока в сообществе разработчиков объектно-ориентированных систем БД не видно работы, которая могла бы сыграть в этом направлении роль, аналогичную роли System R по отношению к реляционным системам. Правда и проблемы ООБД гораздо более сложны, чем решаемые в реляционных системах.
  • Потребность в поддержании в объектно-ориентированной СУБД не только языка (или семейства языков) программирования ООБД, но и развитого языка запросов в настоящее время осознается практически всеми разработчиками. Система должна поддерживать легко осваиваемый интерфейс, прямо доступный конечному пользователю в интерактивном режиме.
  • Наиболее распространенный подход к организации интерактивных интерфейсов с объектно-ориентированными системами баз данных основывается на использовании обходчиков. В этом случае конечный интерфейс обычно является графическим. На экране отображается схема (или подсхема) ООБД, и пользователь осуществляет доступ к объектам в навигационном стиле. Некоторые исследователи считают, что в этом случае разумно игнорировать принцип инкапсуляции объектов и предъявлять пользователю внутренность объектов. В большинстве существующих систем ООБД подобный интерфейс существует, но всем понятно, что навигационный язык запросов - это в некотором смысле шаг назад по сравнению с языками запросов даже реляционных систем. Ведутся активные поиски подходов к организации декларативных языков запросов к ООБД.
  • Беери отмечает существование трех подходов. Первый подход - языки, являющиеся объектно-ориентированными расширениями языков запросов реляционных систем. Наиболее распространены языки с синтаксисом, близким к известному языку SQL. Это связано, конечно, с общим признанием и чрезвычайно широким распространением этого языка. Второй подход основывается на построении полного логического объектно-ориентированного исчисления. По поводу построения такого исчисления имеются теоретические работы, но законченный и практически реализованный язык запросов нам неизвестен. Наконец, третий подход основывается на применении дедуктивного подхода. В основном это отражает стремление разработчиков к сближению направлений дедуктивных и объектно-ориентированных БД.
  • Независимо от применяемого для разработки языка запросов подхода перед разработчиками встает одна концептуальная проблема, решение которой не укладывается в традиционное русло объектно-ориентированного подхода. Понятно, что основой для формулирования запроса должен служить класс, представляющий в ООБД множество однотипных объектов. Но что может представлять собой результат запроса? Набор основных понятий объектно-ориентированного подхода не содержит подходящего к данному случаю понятия. Обычно из положения выходят, расширяя базовый набор концепций множества объектов и полагая, что результатом запроса является некоторое подмножество объектов-экземпляров класса. Это довольно ограничительный подход, поскольку автоматически исключает возможность наличия в языке запросов средств, аналогичных реляционному оператору соединения.
  • Как обычно, основной целью оптимизации запроса в системе ООБД является создание оптимального плана выполнения запроса с использованием примитивов доступа к внешней памяти ООБД.
  • Оптимизация запросов хорошо исследована и разработана в контексте реляционных БД. Известны методы синтаксической и семантической оптимизации на уровне непроцедурного представления запроса, алгоритмы выполнения элементарных реляционных операций, методы оценок стоимости планов запросов.
  • Конечно, объекты могут иметь существенно более сложную структуру, чем кортежи плоских отношений, но не это различие является наиболее важным. Основная сложность оптимизации запросов к ООБД следует из того, что в этом случае условия выборки формулируются в терминах "внешних" атрибутов объектов (методов), а для реальной оптимизации (т.е. для выработки оптимального плана) требуются условия, определенные на "внутренних" атрибутах (переменных состояния).
  • На самом деле похожая ситуация существует и в РСУБД при оптимизации запроса над представлением БД. В этом случае условия также формулируются в терминах внешних атрибутов (атрибутов представления), и в целях оптимизации запроса эти условия должны быть преобразованы в условия, определенные на атрибутах хранимых отношений. Хорошо известным методом такой "предоптимизации" является подстановка представлений, которая часто (хотя и не всегда в случае использования языка SQL) обеспечивает требуемые преобразования. Альтернативным способом выполнения запроса над представлением (иногда единственным возможным) является материализация представления.
  • В системах ООБД ситуация существенно усложняется двумя обстоятельствами. Во-первых, методы обычно программируются на некотором процедурном языке программирования и могут иметь параметры. Т.е. в общем случае тело метода представляет из себя не просто арифметическое выражение, как в случае определения атрибутов представления, а параметризованную программу, включающую ветвления, вызовы функций и методов других объектов. Вторая сложность связана с возможным и распространенным в ООП поздним связыванием: точная реализация метода и даже структура объекта может быть неизвестна во время компиляции запроса.
  • Одним из подходов к упрощению проблемы является открытие видимости некоторых (наиболее важных для оптимизации) внутренних атрибутов объектов. В этом контексте достаточно было бы открыть видимость только для компилятора запросов, т.е. фактически запретить переопределять такие переменные в подклассах. С точки зрения пользователя такие атрибуты выглядели бы как методы без параметров, возвращающие значение соответствующего типа. С нашей точки зрения лучше было бы сохранить строгую инкапсуляцию объектов (чтобы избавить приложение от критической зависимости от реализации) и обеспечить возможности тщательного проектирования схемы ООБД с учетом потребностей оптимизации запросов.
  • Понятно, что возможности оптимизации будут зависеть от особенностей языка программирования, который используется для программирования методов, от особенностей конкретного языка запросов и от того, насколько продуманно спроектирована схема ООБД. В частности, желательно, чтобы используемый язык программирования стимулировал максимально дисциплинированный стиль программирования методов объектов. Язык запросов должен разумно ограничивать возможности пользователей (в частности, в отношении параметров методов, участвующих в условиях запросов). Наконец, в классах схемы ООБД должны содержаться простые методы, не переопределяемые в подклассах и основанные на тех переменных состояния, которые служат основой для организации методов доступа.
  • Заметим, что указанные ограничения не влекут зависимости прикладной программы от особенностей реализации ООБД, поскольку объекты остаются полностью инкапсулированными. Использование в условиях запросов простых методов должно стимулироваться не требованиями реализации, а семантикой объектов.
  • 1.5 Функциональная структура объекта автоматизации
  • В процессе предпроектного обследования и анализа материалов обследования изучается функциональная структура объекта автоматизации --состав обеспечивающих и функциональных подсистем, состоящих из комплексов задач, отдельных задач и процедур управления. Задачи и их комплексы функционально и информационно взаимосвязаны друг с другом. Решение задач организуется на системных принципах в составе АИС (автоматизированной информационной системы) с единым информационным, математическим, программным и другими видами обеспечения.
  • Звеном высшего уровня функциональной структуры факультета является функция управления. Понятие функции базируется на понятии кибернетического контура управления и выражает рациональную форму разделения всего процесса управления по характеру и содержанию решаемых задач. В теории управления различаются такие функции управления, как планирование, нормирование, учет, контроль, анализ, регулирование. При создании АИС функции управления реализуются через функциональные подсистемы. Функциональная подсистема представляет собой часть системы, включающую выделенную по определенному признаку совокупность задач, характеризуемых единством использования результатов в процессе управления. Изучение управленческих процедур предшествует ознакомление с предметной областью в целом. При этом рассматриваются:
  • · организационная структура управления (состав подразделений, их назначение и подчиненность друг другу);
  • · цели, функции и задачи управления.
  • Среди универсальных методов, пригодных для обследования всех функциональных звеньев факультета, наиболее важными являются следующие методы: наблюдение, опрос исполнителей (метод интервью), анализ материалов, личного участия.
  • 1.6 Исследование потоков и структуры информации
  • В процессе предпроектного обследования изучаются состав, структура, форма и содержание информационных сообщений, а также информационные процессы, охватывающие сбор и регистрацию первичной информации, передачу данных, обработку сообщений, организацию хранения и доступа к информации для подготовки и принятия управленческих решений. Информационный анализ предметной области выполняется в трех направлениях:
  • · смысловое содержание сообщений, их информативность для целей управления;
  • · состав и структура сообщений, правила их построения на внемашинном и внутримашинном уровнях;
  • · полезность сообщений для целей системы управления, выполнения функций управления и решения управленческих задач.
  • 1.7 Обследование документов и документооборота системы управления
  • В процессе обследования необходимо создать единый альбом форм документов
  • и установить важнейшие характеристики каждого документа:
  • · система документации, к которой относится документ;
  • · форма документа;
  • · реквизитный состав документа или структура записи массива информации на машинном носителе;
  • · характеристики объема информации документа (количество экземпляров документа).
  • Высшие учебные заведения можно отнести к сложным системам социального типа, эффективное управление которыми являются одной из актуальных задач, стоящих перед его руководством.
  • В настоящее время, для решения этой задачи во многих вузах разрабатываются автоматизированные информационные системы (АИС). Основным недостатком таких разработок является то обстоятельство, что они, автоматизируют работу каждого отдельного элемента системы управления, полностью повторяют существующую организацию управления вузом, определяемую действующими приказами и инструкциями. Это ведет, как правило, к очень незначительному повышению эффективности управления при значительных затратах на приобретение компьютерной техники и обучение персонала.
  • В основу предлагаемого подхода к разработки АИС, поддерживающей эффективное управление вузом, положена идея создания единой интегрированной структуры управления. Анализируя литературу, делаю вывод, что в настоящее время управление любой деятельностью невозможно без анализа большого объема информации и ее обработки с помощью компьютеров. Использование вычислительной техники в различных областях деятельности человека прошло большой путь, который определяется не только развитием собственно техники, но и развитием принципов и методов обработки информации как с точки зрения областей применения, так и сточки зрения широты использования.
  • Производительность труда и качество работы управленческого персонала существенно увеличится с введением новых информационных технологий и автоматизации предметной области.
  • 1.8 Выводы
  • В главе 1, на основе анализа литературы дано теоретическое обоснование разработки проекта «Автоматизация работы специалиста отдела кадров Рыбницкого филиала ПГУ им. Т. Г. Шевченко». В главе рассматриваются цели проектирования информационной системы и ее потребности, рассмотрены также некоторые подходы к проектированию информационных систем. Далее приводится классификация существующих моделей СУБД, на основании чего, делается обоснование выбора реляционной модели. В главе также рассматривается функциональная структура объекта автоматизации и проводится исследование потоков и структуры информации: структура, форма и содержание информационных сообщений, а также информационные процессы, охватывающие сбор и регистрацию первичной информации, передачу данных, обработку сообщений, организацию хранения и доступа к информации для подготовки и принятия управленческих решений.
  • Глава 2. Разработка автоматизированного рабочего места
  • 2.1 Постановка задачи
  • Целью данного дипломного проекта является исследование эффективности обработки задач на примере автоматизации работы специалиста отдела кадров. Для исследования необходимо создать приложение в двух выбранных программных средах. Обосновать выбор и проанализировать полученные результаты: скорость обработки данных, время загрузки приложений, время выполнения операций, объем занимаемой памяти приложениями.
  • Предварительно изучить предметную область, выделить задачи и документы, которые требуют процесса автоматизации. Построить работоспособные приложения.
  • Задача данного дипломного проекта исследовать возможность построения готового приложения для конечного пользователя в принципиально разных и одновременно, функционально схожих средах. Для исследования выбраны Visual FoxPro и Delphi, где Visual FoxPro - это специализированная среда разработки СУБД, a Delphi -универсальная среда разработки программных продуктов разной направленности.
  • В данных пакетах должно быть построено приложение по управлению кадрами. Причем внешний вид, система меню, функциональное назначение, формы, отчеты интерфейса приложений должны быть одинаковы при их реализации. Для чистоты эксперимента построение и прогонка должна осуществляется на одной и той же ЭВМ. При сравнении продуктов должны будут сравниваться объем занимаемого пространства на жестком диске, объем дистрибутива, скорость обработки запросов и субъективная информация, полученная от неискушенного пользователя при подмене одного пакета другим в процессе его работы. С моей стороны должна быть оценена простота и скорость разработки программы, и скорость работы самого пакета разработки.
  • 2.2 Проектирование структуры БД
  • Так как база данных является ядром приложения, при помощи которого достигается решение поставленных задач предметной области, естественным было начать проектирование именно с базы данных.
  • Проектирование базы данных включает выбор следующих элементов:
  • · таблиц, которые будут входить в базу данных;
  • · столбцов, принадлежащих каждой таблице;
  • · взаимосвязей между таблицами и столбцами.
  • Конструирование базы данных связано с построением ее логической структуры. В реляционной модели логическая структура базы абсолютно не зависит от её физической структуры и способа хранения. Логическая структура также не определяется тем, что видит у себя на экране конечный пользователь (это могут быть представления, созданные разработчиком или прикладные программы) .
  • Проектирование баз данных на основе реляционной модели имеет ряд важных преимуществ перед другими моделями.
  • · Независимость логической структуры от физического и пользовательского представления.
  • · Гибкость структуры базы данных - конструктивные решения не ограничивают возможности выполнять в будущем самые разнообразные запросы.
  • В результате исследования предметной области, была спроектирована структура базы данных.
  • Logical Only Entity/Attributes

    • Entity Name

    Entity Logical Only

    Entity Attribute Name

    Comment

    students

    No

    ID

    Идентификатор

    students

    No

    LASTNAME

    Фамилия

    students

    No

    FIRSTNAME

    Имя

    students

    No

    MIDDLENAME

    Отчество

    students

    No

    DEPARTEMEN

    Кафедра

    students

    ...

    Страница:


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

Работы в архивах красиво оформлены согласно требованиям ВУЗов и содержат рисунки, диаграммы, формулы и т.д.
PPT, PPTX и PDF-файлы представлены только в архивах.
Рекомендуем скачать работу.

© 2000 — 2023, ООО «Олбест» Все права защищены