В качестве множеств сущностей отображаются некоторые объекты предметной области, обеспечивающие получение информации, определенной в требованиях к системе. Устанавливаются их атрибуты. Требования к ним. Для каждого множество сущностей необходимо сформулировать бизнес – правила соответствующей предметной области.
Необходимо проанализировать их свойства на предмет их атомарности, то есть, является ли данное свойство атрибутом или другим отношение, с которым у данного объекта есть связь.
Например:
Студент – объект, выполняющий обучение на предметах.
Характеризуется:
фамилией, именем, отчеством (отдельные атрибуты типа строка);
номером зачетной книжки (атрибут целого типа).
Студент обучается на учебном курсе (учебный курс – это отдельное отношение, так как может иметь свои характеристики).
Для выявленных объектов и их атрибутов необходимо выявить бизнес правила, определяющие требования целостности сущности, то есть обязательность значения данного атрибута, уникальность значения данного атрибута, его допустимые значения.
Например:
Фамилия студента состоит из символов, это обязательный атрибут.
Номер зачетной книжки – число, минимальное значение -10000,
Максимальное 99999.
Выявляются бизнес-правила функционирования предметной области определяющие связи выявленных множеств сущностей с другими множествами сущностей. В бизнес-правилах, характеризующих связи должна быть дана следующая информация:
содержания связи;
множественность связи с одной и другой стороны;
обязательности и дополнительных ограничений, ограничений накладываемых на связь.
Каждое выявленное бизнес-правило реализуются в виде фрагмента ER диаграммы.
Результатом данного процесса является построенная ER-диаграмма данных информационной системы.
На ER диаграмме должны быть отображены:
· выявленные множества сущностей;
· их атрибуты;
· ключевые атрибуты;
· связи между сущностями с указанием их типа;
· внешние ключи, через которые реализуются связи.
На основе сформированной ER-модели формируются реляционные отношения. При этом каждое выявленное множество сущностей рассматривается как отношение, кроме того, вводятся при необходимости отношения реализующие связи. Учитываются особенности реализации связей is-as (тип-подтип), связей "многие к многим" и "многие к одному", многосторонние и рекурсивные связи.
Полученные отношения необходимо проанализировать на предмет соответствия их требованиям, предъявляемым к формам нормализации 1NF, 2NF, 3NF и в случае необходимости выполнить преобразования, обеспечивающие выполнения требований нормализации. На этапе нормализации исходный состав отношений может измениться, некоторые отношения могут быть разбиты на несколько отношений.
В учебных целях, в качестве отдельного задания курсовой работы, требуется также сформировать реляционные отношения на основе нормализации некоторого исходного отношения. Для этого необходимо сформулировать исходное отношение, включающее все возможные атрибуты, получение которых необходимо на основании исходных требований к БД. Затем необходимо выполнить нормализацию данного отношения, путем его последовательного приведения к первой, второй, третьей нормальной форме. Работу по нормализации необходимо провести в соответствии с требованиями, изложенными в [2].
Построенная ER модель должна быть преобразована в отношения (таблицы) реляционной БД на основе теоретического материала. Для выполнения данного раздела необходимо:
· выбрать систему управления реляционной базой данных (СУБД), описать ее преимущества, возможности, провести сравнение по перечисленным качествам с другими СУБД;
· создать таблицы на платформе выбранной СУБД;
· описать свойства атрибутов таблиц. Ограничения уровня атрибута, какое требование или выявленное в п. 3.2.2.1.1 бизнес правило оно реализует.
· задать ограничения по ссылкам, указать какое бизнес правило реализует каждое ограничение
Параллельно с даталогическим проектированием необходимо наметить ограничения, которые необходимо реализовать в виде ограничений атрибута, ограничений кортежа, в виде триггера.
На основе информации о планируемых запросах описать создаваемые индексы на соответствующие поля таблиц.
На основании функциональных требований, определенных для информационной системы необходимо определить сценарии взаимодействия пользователей с информационной системой. То есть необходимо определить:
· какую информацию вводит пользователь;
· какие преобразования необходимы для вводимой информации;
· какое взаимодействие с базой данных выполняется.
Обычно выделяются отдельные сценарии для выполнения каждого функционального требования, для каждого типа пользователя, однако для выполнения некоторых требований необходимо выполнение некоторых вспомогательных действий, реализуемых соответствующими сценариями.
В данном пункте необходимо определить, какие компоненты выделяются в составе разрабатываемой системы. Распределить выявленные сценарии по компонентам.
Обычно выделяется компоненты двух уровней:
· клиентская компонента;
· компонента сервера данных.
В серверной компоненте реализуются сценарии, связанные с доступом к данным и их основной обработкой.
В клиентской компоненте обычно реализуется представление данных в удобном для пользователя виде и производится выбор выполняемых действии. В настоящее время существует тенденция построения клиентской компоненты в виде "тонкого клиента", то есть при минимуме закладываемой логики.
В некоторых случаях добавляется компонента прикладной логики, в которой реализуется логика работы предметной области. В этой компоненте помещаются все операции, кроме непосредственной записи и чтения хранимых данных. В рамках курсового проекта достаточно двух уровневой архитектуры.
При выполнении данного пункта, необходимо указать, какие компоненты предварительно выделяются в разрабатываемой системе и, какие сценарии за ними предварительно закрепляются.
Сценарии, предварительно закрепленные за серверной компонентой, уточняются, оформляются в виде операций. Для каждой операции необходимо определить:
· какие исходные данные необходимы для ее выполнения;
· возвращает ли значение данная операция, какого типа, вида (т.е. сами данные или их идентификаторы, индексы), тип информации (справочная или отчетная информация);
· какие элементарные действия, над какими таблицами выполняется данная операция, последовательность выполнения этих действий, существует ли необходимость использования курсоров;
· существуют ли повторяющиеся в других операциях действия, которые можно оформить в виде пользовательских функций;
· существуют ли сопутствующие действия, выполняемые при удалении, добавлении, обновлении кортежей, которые целесообразно оформить в виде триггеров.
Уважаемый посетитель!
Чтобы распечатать файл, скачайте его (в формате Word).
Ссылка на скачивание - внизу страницы.