Главная страница
Навигация по странице:

  • Основные файлы

  • Файлы с условно-постоянной информацией

  • Файлы со справочной информацией

  • Служебные файлы

  • Контрольные вопросы 1. Укажите свойства системы классификацииСтепень информативностиЕмкостьСтепень заполненности системыГибкость2.

  • 8 Моделирование информационного обеспечения 8.1 Моделирование данных Одной из основных частей информационного обеспечения

  • Цель моделирования данных

  • Экземпляр

  • 8.2 Создание логической модели данных Уровни логической модели

  • Проектирование АИС. С аратовский госуниверситет м еханико математический факультет проектирование информационных систем Составил


    Скачать 3.17 Mb.
    НазваниеС аратовский госуниверситет м еханико математический факультет проектирование информационных систем Составил
    АнкорПроектирование АИС.pdf
    Дата05.03.2018
    Размер3.17 Mb.
    Формат файлаpdf
    Имя файлаПроектирование АИС.pdf
    ТипКонтрольные вопросы
    #16260
    страница18 из 22
    1   ...   14   15   16   17   18   19   20   21   22
    по назначению (по типу функциональных подсистем);
    по типу логической организации (файлы с линейной и иерархической структурой записи,
    реляционные, табличные);
    по способу физической организации (файлы с последовательным, индексным и прямым спо- собом доступа).
    Входные файлы создаются с первичных документов для ввода данных или обновления базовых файлов.
    Файлы с результатной информацией предназначаются для вывода ее на печать или передачи по каналам связи и не подлежат долговременному хранению.
    К числу базовых файлов, хранящихся в информационной базе, относят основные, рабочие, проме- жуточные, служебные и архивные файлы.
    Основные файлы должны иметь однородную структуру записей и могут содержать записи с оперативной и условно-постоянной информацией. Оперативные файлы могут создаваться на базе одного или нескольких входных файлов и отражать информацию одного или нескольких первичных документов. Файлы с условно-постоянной информацией могут содержать справочную, расценоч- ную, табличную и другие виды информации, изменяющейся в течение года не более чем на 40%, а следовательно, имеющие коэффициент стабильности не менее 0,6.
    Файлы со справочной информацией должны отражать все характеристики элементов матери- ального производства (материалы, сырье, основные фонды, трудовые ресурсы и т.п.). Как правило,
    справочники содержат информацию классификаторов и дополнительные сведения об элементах Ма- териальной сферы, например о ценах. Нормативно-расценочные файлы должны содержать данные о нормах расхода и расценках на выполнение операций и услуг. Табличные файлы содержат све- дения об экономических показателях, считающихся постоянными в течение длительного времени

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

    • релевантность ИБ, под которой подразумевается способность системы осуществлять поиск и выдавать информацию, точно соответствующую запросам пользователей;
    • удобство языкового интерфейса, позволяющее быстро формулировать запрос к ИБ;
    • разграничение прав доступа, т.е. определение для каждого пользователя доступных типов за- писей, полей, файлов и видов операций над ними.
    Существуют следующие способы организации ИБ: совокупность локальных файлов, поддержи- ваемых функциональными пакетами прикладных программ, и интегрированная база данных, осно- вывающаяся на использовании универсальных программных средств загрузки, хранения, поиска и ведения данных, т.е. системы управления базами данных (СУБД).
    Локальные файлы вследствие специализации структуры данных под задачи обеспечивают, как правило, более быстрое время обработки данных. Однако недостатки организации локальных фай- лов, связанные с большим дублированием данных в информационной системе и, как следствие,
    несогласованностью данных в разных приложениях, а также негибкостью доступа к информации,
    перекрывают указанные преимущества. Поэтому организация локальных файлов может применять- ся только в специализированных приложениях, требующих очень высокой скорости реакции при импорте необходимых данных.
    Интегрированная ИБ, т.е. база данных (БД) — это совокупность взаимосвязанных, хранящихся вместе данных при такой минимальной избыточности, которая допускает их использование опти- мальным образом для множества приложений.
    Централизация управления данными с помощью СУБД обеспечивает совместимость этих данных,
    уменьшение синтаксической и семантической избыточности, соответствие данных реальному состо- янию объекта, разделение хранения данных между пользователями и возможность подключения новых пользователей. Но централизация управления и интеграция данных приводят к проблемам
    другого характера: необходимости усиления контроля вводимых данных, необходимости обеспечения соглашения между пользователями по поводу состава и структуры данных, разграничения доступа и секретности данных.
    Основными способами организации БД являются создание централизованных и распределенных
    БД. Основным критерием выбора способа организации ИБ является достижение минимальных тру- довых и стоимостных затрат на проектирование структуры ИБ, программного обеспечения системы ведения файлов, а также на перепроектирование ИБ при возникновении новых задач.
    Контрольные вопросы
    1.
    Укажите свойства системы классификации
    Степень информативности
    Емкость
    Степень заполненности системы
    Гибкость
    2.
    Укажите характерные особенности иерархической системы классификаторов наличие в системе неограниченного количества признаков классификации использование параллельно нескольких независимых признаков (в качестве основания клас- сификации)
    соподчиненность признаков классификации

    3.
    Укажите типы многоаспектных систем классификации
    Фасетная
    Дескрипторная
    Иерархическая
    4.
    Укажите характеристики кода системы кодирования информации
    Структура кода
    Основание кодирования
    Емкость
    Коэффициент избыточности
    Длина
    Степень информативности
    5.
    Укажите, на чем базируются последовательные системы кодирования
    На разрядной или комбинированной системе кодирования
    На предварительной классификации по иерархической системе классификации
    На использовании фасетной системы классификации
    6.
    Укажите, на чем базируются параллельные системы кодирования
    На предварительной классификации по иерархической системе классификации
    На использовании фасетной системы классификации
    На разрядной или комбинированной системе кодирования

    7.
    Укажите, какие файлы относятся к числу базовых файлов, хранящихся в информационной базе
    Архивные
    Промежуточные
    Файлы с результатной информацией
    Основные
    Служебные
    Рабочие
    8.
    Укажите, какие шаги обычно включает в себя процесс проектирования форм электронных до- кументов
    Определения перечня макетов экранных форм
    Определение содержания формы ЭД
    Апробация работы ЭД
    Определение содержания макетов
    Программирование разработанных макетов экранных форм и их отладка
    Создание структуры ЭД
    9.
    Укажите, какие требования должна обеспечивать организация хранения файлов в информаци- онной базе
    Целостность хранимой информации
    Реализуемость системы, обеспечивающая требуемую степень сложности структуры ИБ
    Удобство языкового интерфейса

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

    8 Моделирование информационного
    обеспечения
    8.1 Моделирование данных
    Одной из основных частей информационного обеспечения является информационная база. Ин-
    формационная база (ИБ) представляет собой совокупность данных, организованная определенным способом и хранимая в памяти вычислительной системы в виде файлов, с помощью которых удовле- творяются информационные потребности управленческих процессов и решаемых задач. Разработка
    БД выполняется с помощью моделирования данных. Цель моделирования данных состоит в обес- печении разработчика ИС концептуальной схемой базы данных в форме одной модели или несколь- ких локальных моделей, которые относительно легко могут быть отображены в любую систему баз данных. Наиболее распространенным средством моделирования данных являются диаграммы
    “сущность-связь” (ERD). С помощью ERD осуществляется детализация накопителей данных DFD
    – диаграммы, а также документируются информационные аспекты бизнес-системы, включая иденти- фикацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов)
    и их связей с другими объектами (отношений).
    3

    Базовые понятия ERD
    Сущность (Entity) — множество экземпляров реальных или абстрактных объектов (людей, событий,
    состояний, идей, предметов и др.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр (например, АЭРОПОРТ, а не ВНУКОВО).
    Каждая сущность должна обладать уникальным идентификатором. Каждый экземпляр сущности должен однозначно идентифицироваться и отличаться от всех других экземпляров данного типа сущности. Каждая сущность должна обладать некоторыми свойствами:
    • иметь уникальное имя; к одному и тому же имени должна всегда применяться одна и та же интерпретация; одна и та же интерпретация не может применяться к различным именам, если только они не являются псевдонимами;
    • иметь один или несколько атрибутов, которые либо принадлежат сущности, либо наследуются через связь;
    • иметь один или несколько атрибутов, которые однозначно идентифицируют каждый экземпляр сущности.
    Каждая сущность может обладать любым количеством связей с другими сущностями модели.
    Связь (Relationship) — поименованная ассоциация между двумя сущностями, значимая для рас- сматриваемой предметной области. Связь — это ассоциация между сущностями, при которой каж- дый экземпляр одной сущности ассоциирован с произвольным (в том числе нулевым) количеством экземпляров второй сущности, и наоборот.

    Атрибут (Attribute) — любая характеристика сущности, значимая для рассматриваемой предмет- ной области и предназначенная для квалификации, идентификации, классификации, количественной характеристики или выражения состояния сущности. Атрибут представляет тип характеристик или свойств, ассоциированных с множеством реальных или абстрактных объектов (людей, мест, собы- тий, состояний, идей, предметов и т.д.). Экземпляр атрибута — это определенная характеристика отдельного элемента множества. Экземпляр атрибута определяется типом характеристики и ее зна- чением, называемым значением атрибута. На диаграмме "сущность-связь"атрибуты ассоциируются с конкретными сущностями. Таким образом, экземпляр сущности должен обладать единственным определенным значением для ассоциированного атрибута.
    Метод IDEFI
    Наиболее распространенными методами для построения ERD-диаграмм являются метод Баркера и метод IDEFI.
    Метод Баркера основан на нотации, предложенной автором, и используется в case-средстве Oracle
    Designer.
    Метод IDEFI основан на подходе Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. На основе совершенствования метода IDEFI со- здана его новая версия — метод IDEFIX, разработанный с учетом таких требований, как простота для изучения и возможность автоматизации. IDEFIX-диаграммы используются в ряде распростра- ненных CASE-средств (в частности, ERwin, Design/IDEF).
    В методе IDEFIX сущность является независимой от идентификаторов или просто независимой,
    если каждый экземпляр сущности может быть однозначно идентифицирован без определения его отношений с другими сущностями. Сущность называется зависимой от идентификаторов или просто зависимой, если однозначная идентификация экземпляра сущности зависит от его отношения к

    Рис. 8.1: Независимые от идентификации сущности
    Рис. 8.2: Зависимые от идентификации сущности другой сущности (рис.
    8.1
    ,
    8.2
    ).
    Каждой сущности присваиваются уникальные имя и номер, разделяемые косой чертой "/"и поме- щаемые над блоком.
    Связь может дополнительно определяться с помощью указания степени или мощности (количества экземпляров сущности-потомка, которое может порождать каждый экземпляр сущности-родителя).
    В IDEFIX могут быть выражены следующие мощности связей:
    • каждый экземпляр сущности-родителя может иметь ноль, один или более одного связанного с ним экземпляра сущности-потомка;

    Рис. 8.3: Графическое изображение мощности связи
    • каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экзем- пляра сущности-потомка;
    • каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экзем- пляра сущности-потомка;
    • каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпля- ров сущности-потомка.
    Если экземпляр сущности-потомка однозначно определяется своей связью с сущностью-родителем,
    то связь называется идентифицирующей, в противном случае — неидентифицирующей.
    Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком, с точкой на конце линии у сущности-потомка (рис.
    8.3
    ). Мощность связей может принимать следую- щие значения: N — ноль, один или более, Z — ноль или один, Р — один или более. По умолчанию мощность связей принимается равной N.
    Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплош- ной линией. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора
    сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).
    Пунктирная линия изображает неидентифицирующую связь (рис.
    8.4
    ). Сущность-потомок в неиден- тифицирующей связи будет не зависимой от идентификатора, если она не является также сущностью- потомком в какой-либо идентифицирующей связи.
    Атрибуты изображаются в виде списка имен внутри блока сущности. Атрибуты, определяющие первичный ключ, размещаются наверху списка и отделяются от других атрибутов горизонтальной чертой (рис.
    8.4
    ).
    Сущности могут иметь также внешние ключи (Foreign Key), которые могут использоваться в качестве части или целого первичного ключа или неключевого атрибута. Для обозначения внешнего ключа внутрь блока сущности помещают имена атрибутов, после которых следуют буквы FK в скобках (рис.
    8.4
    ).
    8.2 Создание логической модели данных
    Уровни логической модели
    Различают три уровня логической модели, отличающихся по глубине представления информации о данных:
    • диаграмма сущность-связь (Entity Relationship Diagram, ERD);
    • модель данных, основанная на ключах (Key Based model, KB);
    • полная атрибутивная модель (Fully Attributed model, FA).

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

    Сущности и атрибуты
    Каждая сущность является множеством подобных индивидуальных объектов, называемых экзем- плярами. Каждый экземпляр индивидуален и должен отличаться от всех остальных экземпляров.
    Атрибут выражает определенное свойство объекта. С точки зрения БД (физическая модель) сущ- ности соответствует таблица, экземпляру сущности — строка в таблице, а атрибуту — колонка таблицы.
    Построение модели данных предполагает определение сущностей и атрибутов, т. е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которых должна со-
    храняться. сущности должны иметь наименование с четким смысловым значением, именоваться существительным в единственном числе, не носить "технических"наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра. Примером может быть сущности Заказчик (но не Заказчики!) с атрибутами Номер заказчика, Фамилия заказ- чика и Адрес заказчика. На уровне физической модели ей может соответствовать таблица Customer с колонками Customer_number, Customer_name и Customer_address. Каждая сущность должна быть полностью определена с помощью текстового описания. Для внесения дополнительных комментариев и определений к сущности служат свойства, определенные пользователем (UDP).
    Как было указано выше, каждый атрибут хранит информацию об
    1   ...   14   15   16   17   18   19   20   21   22


    написать администратору сайта