Проектирование информационных систем
 Скачать 307.95 Kb.
|
|
Суперкласс – тип сущности, включающий разные подклассы, которые необходимо представить в модели данных. Подкласс - тип сущности, который исполняет отдельную роль, а также является членом суперкласса. Связь между суперклассом и подклассом относится к типу 1:1 и называется связью «суперкласс/подкласс». Типы сущностей делятся на суперклассы и подклассы, расширяющие свои суперклассы. Допускается множественное наследование (shared subclass). Полное и частичное участие в специализации. Полное – каждая сущность суперкласса является членом какого-либо подкласса по этой специализации. Частичная – наоборот, сущности суперкласса не обязаны быть специализированными. Пересечение/непересечение и полное/частичное участие – ортогональные характеристики. Категоризация – моделирование одного подкласса-категории со связью, которая охватывает несколько разных суперклассов. При этом каждый экземпляр сущности класса-категории настедует атрибуты только одного суперкласса. К категориям применимо понятие полного/частичного участия. Процесс моделирования: Спецификации требований Определение типов сущностей Определение типов связей Определение показателей кардинальности и степеней участия сторон для типов связей Определение атрибутов и связывание их с типами сущностей и связей Определение потенциальных и первичных ключей Специализация (выделение подклассов) / генерализация (выделение суперклассов) типов сущностей Категоризация типов сущностей Программные средства для построения ER-диаграмм: ERwin, Visio Преобразование ER-модели в реляционную: Типы сущностей - отношения (атрибуты и ключи переходят практически без изменений) Суперклассы/подклассы – связь на основе внешнего ключа, указывающего на первичный ключ суперкласса. Связь One-To-One: внешний ключ + ограничение целостности, либо пара внешних ключей. Связь One-To-Many: внешний ключ. Связь Many-To-Many: специальная таблица пересечения, состоящая из 2 внешних ключей, каждый кортеж которой представляет собой экземпляр связи. Атрибуты связей – уходят во внешние ключи. При использовании CASE-средств обычно можно произвести подобное преобразование автоматически. Правило нахождения и особенности связи с показателем кардинальности M:N. Признаки ассоциативной таблицы. Каждую связь характеризуют два структурных ограничения: показатель кардинальности; степень участия. Показатель кардинальности описывает количество возможных связей для каждой сущности-участницы связи. Для нахождения показателя кардинальности необходимо использовать следующее правило, состоящее из трех шагов: Выделяется один экземпляр первой сущности и проверяется, со сколькими экземплярами второй сущности он может вступать в связь. При этом не учитывается временной фактор, другими словами - со сколькими экземплярами второй сущности он может вступать в связь в любое время. Выделяется один экземпляр второй сущности и проверяется, со сколькими экземплярами первой сущности он может вступать в связь в любое время. Результаты первого и второго шага сравниваются, затем выбирается показатель кардинальности данной связи:  Показатель кардинальности зависит от бизнес-правил описываемой организации, а также от набора атрибутов сущностей, вступающих в эту связь. Степень участия определяет, зависит ли существование некоторой сущности от участия в этой связи другой сущности. ля определения степени участия необходимо задать вопрос все ли экземпляры первой сущности принимают участие в заявленной связи? Если ответ - да, то степень участия первой сущности в этой связи – полная, если ответ - нет, то степень участия первой сущности в этой связи – частичная. Такой же вопрос задается и для второй сущности-участнице этой связи. Ответы заносятся в таблицу № 2. Пример. Результатом данной лабораторной работы является заполненная таблица.  Способы реализации транзакций. Работа по проектированию производных атрибутов. Виды реализации производных атрибутов. Связь – некоторая ассоциация между двумя сущностями, значимая для рассматриваемой предметной области. Примерами связей могут являться родственные отношения «отец–сын», производственные – «начальник-подчиненный» или произвольные – «иметь в собственности», «обладать свойством». Атрибут (столбец, поле) – свойство сущности или связи. Связь между сущностями характеризуется: типом связи (1:1, 1:N, N:М); классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности – обязательный, иначе – необязательный. Неключевыми являются атрибуты, значения которых зависят от значений первичного ключа или составного первичного ключа. Эти не ключевые атрибуты должны зависеть от значения ключа, полного ключа, и ни от чего кроме ключа. Селективные атрибуты - атрибуты, используемые для идентификации единственного экземпляра сущности, когда ключ не уникален. Также называются вторичными ключами . Групповой атрибут - атрибут, объединяющий группу более детальных атрибутов. Атрибуты повторяющейся группы - атрибуты, представляющие несколько включений одного атрибута в рамках сущности. Производные атрибуты - атрибуты, чьи значения определяются из значений других атрибутов. Атрибуты основных данных - атрибуты, которые не являются селективными, групповыми, атрибутами повторяющейся группы или производными. Селективные, групповые и атрибуты повторяющейся группы не должны присутствовать в логической модели, приведенной к третьей нормальной форме. Селективные атрибуты должны стать частью первичного ключа, если они нужны для идентификации единственного экземпляра сущности. Групповые атрибуты являются многозначными. По моему мнению, групповые атрибуты лучше всего представлять в модели кодовыми или классификационными сущностями. В третьей нормальной форме не ключевые атрибуты должны быть простыми (основными) или производными атрибутами. Структура информационной системы. Предназначение и состав основных компонент ИС. Структуру информационной системы составляет совокупность отдельных ее частей, называемых подсистемами.  Подсистема – это часть системы, выделенная по какому-либо признаку. Функциональная часть информационной системы обеспечивает выполнение задач и назначение информационной системы. Фактически здесь содержится модель системы управления организацией. В рамках этой части происходит трансформация целей управления в функции, функций – в подсистемы информационной системы. Подсистемы реализуют задачи. Обычно в информационной системе функциональная часть разбивается на подсистемы по функциональным признакам: · уровень управления (высший, средний, низший); · вид управляемого ресурса (материальные, трудовые, финансовые и т.п.); · сфера применения (банковская, фондового рынка и т.п.); · функции управления и период управления. Например, информационная система управления технологическими процессами – компьютерная информационная система, обеспечивающая поддержку принятия решений по управлению технологическими процессами с заданной дискретностью и в рамках определенного периода управления. В табл. 2.3 указаны некоторые из возможных информационных систем, однако их достаточно для иллюстрации связи функций систем и функций управления. Функциональный признак определяет назначение подсистемы, а также ее основные цели, задачи и функции. Структура информационной системы может быть представлена как совокупность ее функциональных подсистем, а функциональный признак может быть использован при классификации информационных систем. Например, информационная система производственной фирмы имеет следующие подсистемы: управление запасами, управление производственным процессом и др. В хозяйственной практике производственных и коммерческих объектов типовыми видами деятельности, которые определяют функциональный признак классификации информационных систем, являются: производственная, маркетинговая, финансовая, кадровая. Этапы проектирования БД и пользовательских приложений. Цель и виды работ на этапе концептуального проектирования базы данных и пользовательских приложений. Законы проектирования баз данных: 1.Системный анализ предметной области 2.Инфологическое проектирование 3.Выбор СУБД 4.Датологическое проектирование 5.Физическое проектирование На первом этапе проектирования баз данных рассматриваются цели и задачи с помощью которой они будут решатся. Анализируются информационные потребности будущих пользователей баз данных. Рассматриваются формы входных и выходных потоков, которые будут составлять основу баз данных. Затем уточняются алгоритмы и процедуры обработки данных хранимой в базе данных. Формируются требования, которым должна удовлетворять проектируемая база данных и определяется примерный список объектов предметной области, свойства которых будут использоваться при разработке базы данных. II Инфологическое проектирование На второй стадии проектирования выполняется моделирование данных. Моделирование данных – это процесс создания логической структуры данных. Существует два подхода к моделированию данных: Модель «Сущность-связь» Семантическая объектная модель Эти модели представляют собой языки для описания структуры данных и их связей в представлениях пользователей. Моделирование данных, подобно блок-схемам, отражают логику программы. Модель «Сущность-Связь» Сущность – это объект, идентифицируемый в рабочей среде пользователя за которым пользователь хотел бы наблюдать. Класс сущностей – это совокупность сущностей, которая описывается структурой, либо форматом сущностей, составляющих этот класс. Экземпляр сущности – представляет собой конкретную сущность. Атрибуты сущности – это свойства сущности, которые описывают характеристики сущности. Идентификаторы – это атрибуты, с помощью которых экземпляры именуются или идентифицируются. Если идентификатор указывает на один экземпляр сущности, то его значение называется уникальным. Если идентификатор не является уникальным, то его значение определяется некоторым множеством экземпляров сущности. Связи – это взаимоотношения сущностей выраженная связями. Модель «Сущность-Связь» включает в себя классы связей и экземпляры связей. Классы связей – это взаимоотношения между классами сущностей. Экземпляры связей – это взаимоотношения между экземплярами сущностей.Типы связей: Связь один к одному (1:1) – одиночный экземпляр сущности одного типа связан с одиночным экземпляром сущности другого типа. Связь один ко многим (1:М) – один экземпляр сущности связан со многими экземплярами другой сущности. Связь многие ко многим (М:N) – несколько экземпляров одной сущности связаны с несколькими экземплярами другой сущности. Модель «Сущность-Связь» или ER-диаграммы включают в себя изображения сущностей в виде прямоугольников (или прямоугольников с закругленными углами), а связей в виде ромбиков (или ромбиков с закругленными углами). На ER-диаграммах атрибуты обозначаются эллипсами. Если атрибутов у сущности много, то чтобы не загружать ER-диаграмму, атрибуты помещают в прямоугольник, в котором идет перечисление всех атрибутов сущности. Этапы проектирования БД и пользовательских приложений. Цель и виды работ на этапе логического проектирования базы данных и пользовательских приложений. 1.Системный анализ предметной области 2.Инфологическое проектирование 3.Выбор СУБД 4.Датологическое проектирование 5.Физическое проектирование На первом этапе проектирования баз данных рассматриваются цели и задачи с помощью которой они будут решатся. Анализируются информационные потребности будущих пользователей баз данных. Рассматриваются формы входных и выходных потоков, которые будут составлять основу баз данных. Затем уточняются алгоритмы и процедуры обработки данных хранимой в базе данных. Формируются требования, которым должна удовлетворять проектируемая база данных и определяется примерный список объектов предметной области, свойства которых будут использоваться при разработке базы данных. При выборе СУБД руководствуются следующими соображениями: аппаратное обеспечение, на котором в дальнейшем будет работать проектируемая база данных; системное программное обеспечение, с которым будет в последствии работать проектируемая база данных и соответствующее ей приложения; методология и подходы, к программированию реализованные в той или иной СУБД; модель данных, которая встроена в конкретную СУБД; Выбор СУБД полностью определяется на II этапе построения базы данных, т. к. оно зависит от той модели данных, которая встроена в выбранную СУБД. IV Датологическое проектирование После того, как выбор СУБД завершён, необходимо приступить к проектированию датологической модели базы данных. При формировании датологической схемы, каждая из определённых в концептуальной схеме сущностей отображается в таблицу, которая является одним отношением. При этом следует учитывать ограничения на размер таблиц, которые накладывает конкретная СУБД. На этапе логического проектирования разрабатывается логическая структура БД, соответствующая инфологической модели ПО. Решение этой задачи существенно зависит от модели данных, поддерживаемой выбранной СУБД. Результатом выполнения этого этапа являются схемы БД концептуального и внешнего уровней архитектуры, составленные на языках определения данных (DDL) выбранной СУБД. Этапы проектирования БД и пользовательских приложений. Цель и виды работ на этапе физического проектирования базы данных и пользовательских приложений. 1.Системный анализ предметной области 2.Инфологическое проектирование 3.Выбор СУБД 4.Датологическое проектирование 5.Физическое проектирование Физическое проектирование базы данных - процесс подготовки описания реализации базы данных на вторичных запоминающих устройствах; на этом этапе рассматриваются основные отношения, организация файлов и индексов, предназначенных для обеспечения эффективного доступа к данным, а также все связанные с этим ограничения целостности и средства защиты. Физическое проектирование является третьим и последним этапом создания проекта базы данных, при выполнении которого проектировщик принимает решения о способах реализации разрабатываемой базы данных. Во время предыдущего этапа проектирования была определена логическая структура базы данных (которая описывает отношения и ограничения в рассматриваемой прикладной области). Хотя эта структура не зависит от конкретной целевой СУБД, она создается с учетом выбранной модели хранения данных, например реляционной, сетевой или иерархической. Однако, приступая к физическому проектированию базы данных, прежде всего необходимо выбрать конкретную целевую СУБД. Поэтому физическое проектирование неразрывно связано с конкретной СУБД. Между логическим и физическим проектированием существует постоянная обратная связь, так как решения, принимаемые на этапе физического проектирования с целью повышения производительности системы, способны повлиять на структуру логической модели данных. Как правило, основной целью физического проектирования базы данных является описание способа физической реализации логического проекта базы данных. Этапы физического проектирования баз данных: Перенос глобальной логической модели данных в среду целевой СУБД. Проектирование основных отношений. Разработка способов получения производных данных. Реализация ограничений предметной области. Проектирование физического представления базы данных. Анализ транзакций. Выбор файловой структуры. Определение индексов. Определение требований к дисковой памяти. Проектирование пользовательских представлений. Разработка механизмов защиты. Обоснование необходимости введения контролируемой избыточности. Текущий контроль и настройка операционной системы. |