СОДЕРЖАНИЕ И ТРЕБОВАНИЯ К ОФОРМЛЕНИЮ КП ПО КУРСУ “УПРАВЛЕНИЕ ДАННЫМИ”

Курсовой проект должен содержать разделы в соответствии с пунктами раздела 3 данных методических указаний. То есть он должен включать разделы:

1.Уточнение постановки задачи.

А) Необходимо привести постановку задачи в исходном виде. На основании исходной постановки сформулировать цель вашей БД,  то есть какого типа информацию она будет содержать, какие функции выполнять.

На данном этапе необходимо определить основные объекты предметной области, данные о которых необходимо хранить в БД.

Б) Необходимо установить какую информацию, в каком виде необходимо получать на основании создаваемой базы. То есть, определить предполагаемый состав запросов. На основании каких данных будут выполнятся запросы. Какие атрибуты, каких объектов будут выдаваться в качестве результатов запросов.

В) Необходимо установить необходимый способ ведения БД, то есть какие  и каким образом данные в БД будут изменяться (в результате запросов, пользователем, автоматически специальными приложениями)

Г ) Предполагаемый круг пользователей БД. Типы пользователей.

2. Формирование исходных отношений-таблиц.

2.1. Формирование отношений на основе ER моделирования и их нормализация .

Определение, анализ и уточнение бизнес-правил, на основании которых производится следующее:

Каждый выявленный объект рассматривается как множество сущностей.

Строятся сегменты ER модели для соответствующих бизнес-правил на которых отображается связи и множества сущностей, описанных данным бизнес-правилом.

Полученные отношения необходимо проанализировать на предмет соответствия их требованиям, предъявляемым к формам нормализации 1NF, 2NF, 3NF и в случае необходимости выполнить преобразования, обеспечивающие выполнения требований нормализации

При этом производится определение необходимых первичных, вторичных и внешних ключей.

Первичный ключ —  уникальный ключ, идентифицирующий отдельный кортеж отношения. По значению первичного  ключа производится связь подчиненных отношений с базовым отношением. Если отношение участвует в связи один к одному, один к многим, со стороны одного, то оно обязательно должно содержать первичный ключ, однако в общем случае наличие первичного ключа является желательным, но не обязательным. Внешний ключ, это обязательный атрибут (или комбинация атрибутов) в связи “многие ко многим” со стороны “многих”, значения которого должны или совпадать со значениями первичного ключа в базовой таблице или быть пустыми (null), Вторичный ключ – это атрибут (или их комбинация) используемый исключительно в целях поиска данных (его уникальность не обязательна).,

Для каждого отношения должен быть сделан вывод о соответствии его требованиям 1NF, 2NF, 3NF.

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

В случае целесообразности проводится и обосновывается денормализация.

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

3. Даталогическое проектирование. То есть формирование таблицы БД.

3.0 Построенная ER модель должна быть преобразована в отношения реляционной БД. По принципам, рассмотренным на лекциях.

3.1. Выбор системы управления реляционной базой данных. Описать её преимущества, возможности, провести сравнение по перечисленным качествам с другими СУРБД.

3.2. Создание таблиц. Для полученных отношений создаются таблицы.

Описать какие табл. Описываются поля таблиц, их тип, указываются ключевые поля. Как реализуются связи.

3.3. Создание индексов.

Индексы убыстряют работу базы, однако увеличивают ее объем. Состав индексов должен быть достаточным но не избыточным. Индексы создаются для атрибутов – первичных, внешних ключей, и вторичных ключей (для поиска данных). В случае отсутствия индексов в проекте  необходимо обосновать отказ от их использования. Для учебного проекта как правило объем кортежей не превышает критической точки, после которой индексы повышают эффективность БД.

4. Проектирование запросов.

4.1. Описать основные запросы написать их назначение, написать их представление на основе SQL.

4.2. Описать  используемые хранимые процедуры и пользовательские функции. Их назначение.

5. Проектирование клиентского интерфейса.

5.1. Определение состава форм.

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

5.2. Проектирование форм. Какими средствами (Access, С++Bilder, и.т.д) какие объекты использованы для их создания, какие основные свойства объектов задаются, какие функции реализованы.

5.4. Проектирование отчетов

Указать состав отчета, назначение, какие группирования, функции заложены. Какими средствами, какие объекты использованы для их создания. Обращение к отчетам.

6. Организационное проектирование.

Указать группы пользователей. Какие роли необходимы для реализации этих групп. Функции и права отдельных ролей. Примерный состав пользователей в группах.

Примерный состав рабочих мест, тип компьютеров (серверов и клиентов), реализация связи.(тип сети).

И так в записке все пункты, что приведены выше.

Рисунки схем ER модель.

Схема БД ( связи таблиц)

Копии рабочих форм с пояснениями.

Схема рабочей группы.

В приложении пример отчета.

Ссылка на основную публикацию
Adblock
detector