Методические указания по концептуальному этапу проектирования БД

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

Сценарий 1:

· на основании изучения информационных потоков сформировать максимально полный список атрибутов будущей БД (входные и выходные данные для всех операций бизнес-процессов);

· сгруппировать атрибуты по сущностям;

· выявить связи между сущностями и определить их характеристики.

Сценарий 2:

· на основании описания предметной области выявить сущности;

· определить предварительный список атрибутов каждой сущности;

· выявить и описать связи между сущностями.

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

Рассмотрим сценарий 2 более подробно:

· по описанию предметной области ответить на вопрос: «Информация о ком или о чём должна храниться в БД?»;

· составить предварительный список сущностей из ответов на поставленный вопрос;

· по умолчанию добавить в список сущность ДАТА, что позволит в дальнейшем учитывать фактор времени при выявлении связей между сущностями;

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

o значение атрибута не зависит от существования экземпляров других сущностей из списка;

o атрибут принимает атомарное значение у каждого экземпляра сущности;

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

· если какой-то атрибут не может быть приписан ни одной сущности, то, либо он является атрибутом сущности, которой нет в списке, либо – это атрибут связи;

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

o связи в описании предметной области обычно представлены глаголами (как в текстовом описании, так и в моделях бизнес-процессов);

o для каждой выявленной связи определить её тип (1:1, 1:m, n:m,n-арная);

o для всех связей, кроме n-арной, определить мощность и обязательность;

o определить атрибуты связей, если они имеются;

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

· представить концептуальную модель данных в выбранной нотации;

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

· внести необходимые исправления и дополнения в модель данных.

Более подробно указанный сценарий рассматривается в лекционном курсе по дисциплине «Базы данных».

Методические указания по описанию математических разделов

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

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

Порядок описания реляционной модели данных:

· отношения;

· атрибуты и их домены;

· правила целостности по сущностям и по ссылкам;

· бизнес-правила;

· запросы на языке реляционной алгебры или реляционного исчисления.

Методические указания по описанию компонентов технического обеспечения

В разделе, посвящённом компонентам технического обеспечения, необходимо рассмотреть:

· выбор (если в ТЗ отсутствует требование в виде указания конкретного варианта архитектуры) и/или описание архитектуры, в которой будет реализована задача проектирования по теме курсовой работы;

· выбор и/или обоснование платформы;

· выбор и/или обоснование типовой конфигурации ТС (клиент, сервер и т.п.).