Файл: Контрольная работа БД ИТАП 2013.doc

Пояснительная записка выполняется на одной стороне листа бумаги формата А4. Общий объем не менее 20 страниц (без приложения). Все таблицы, рисунки, схемы, формулы, графики должны быть пронумерованы и снабжены подписями и ссылками в тексте. Оформление пояснительной записки должно соответствовать требованиям: ГОСТ 7.32-2001 СИБИД. Отчет о научно-исследовательской работе. Структура и правила оформления; ГОСТ 2.105—95 ЕСКД. Общие требования к текстовым документам. При оформлении пояснительной записки рекомендуется пользовать методическими указаниями, изложенными в этом методическом пособии.

Материалы в пояснительной записке следует располагать в следующем порядке:

• Титульный лист (приложение 1);

• Техническое задание на проектирование;

• Содержание;

• Введение;

• Раздел 1. Системный анализ предметной области (ПО) и анализ требований к базе данных;

• 1.1. Формулировка задания; 1.2. Конкретизация ПО; 1.3. Требования к хранению данных; 1.5. Сроки хранения информации; 1.6. Ситуации, изменяющие БД; 1.7. Основные запросы (на естественном языке).

• Раздел 2. Концептуальное моделирование предметной области;

• 2.1. ER-диаграмма модели ПО (на ERwin или Silveran); 2.2. Оценка мощностных характеристик сущностей и связей.

• Раздел 3. Концептуальное проектирование;

• 3.1. Концептуальная модель БД (ERwin или Silveran).

• Раздел 4. Логическое проектирование.

• 4.1. ER-диаграмма БД (ERwin Logical); 4.2. Схема отношений БД (ERwin Physical); 4.3. Схемы реляционной БД; 4.4. Схемы основных запросов.

• Раздел 5. Физическое проектирование (СУБД Visual FoxPro 9.0)

• 5.1. Создание БД; 5.2. Создание таблиц; 5.3. Заполнение таблиц данными контрольного примера; 5.4. Создание электронных форм (2-3), запросов (4-5) и отчетов (4-5) в среде СУБД Visual FoxPro 9.0 ); 5.5 Оценка размеров БД и каждого из файлов.

• Заключение;

• Список использованных источников;

• Приложение (приложения).

Законченная пояснительная записка подписывается студентом. Изложение должно быть ясным и четким, без повторений. Следует избегать необоснованного использования в тексте пояснительной записки большого количества теоретического материала.

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

Графическая часть проекта является не иллюстративным материалом, а технической документацией на разработанный студентом проект БД ЭИС. Графический материал, помещенный в пояснительной записке - по формату, условным обозначениям, шрифтам и масштабам должен соответствовать требованиям единой системы конструкторской документации (ЕСКД). При выполнении графического материала с использованием CASE-средства ERWin Data Modeler в нотации IDEF1X, этому международному стандарту.

6. Методика выполнения контрольной работы

6.1. Техническое задание на проектирование

Выполняется по ГОСТ 34.602-89. Техническое задание на создание автоматизированной системы. При этом студентом заполняются следующие разделы (и их подразделы): 1) общие сведения; 2) назначение и цели создания (развития) системы; 3) характеристика объектов автоматизации; 4) требования к системе; 5) состав и содержание работ по созданию системы.

6.2. Введение

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

6.3. Системный анализ и анализ требований

Первыми выполняемыми задачами являются системный анализ и анализ требований. Они закладывают фундамент для решения последующих задач.

Системный анализ проводится с целью:

1) выяснения потребностей заказчика;

2) оценки выполнимости системы;

3) выполнения экономического и технического анализа;

4) распределения функций по элементам компьютерной системы (аппаратуре, программам, людям, базам данных и т. д.);

5) определения стоимости и ограничений планирования;

6) создания системной спецификации.

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

Анализ требований дает возможность:

1) определить функции и характеристики программного продукта;

2) обозначить интерфейс продукта с другими системными элементами;

3) определить проектные ограничения программного продукта;

4) построить модели: данных, режимов функционирования продукта;

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

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

Важнейшая цель проектирования информационной модели - выработка непротиворечивой структурированной интерпретации реально существующей информации изучаемой предметной области и взаимодействия между ее структурными компонентами

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

Методология IDEF1X - один из подходов к семантическому моделированию данных, основанный на концепции "сущность-связь" (Entity-Relationship). Это инструмент для анализа информационной структуры систем различной природы. Информационная модель, построенная с помощью IDEF1X-методологии, отображает логическую структуру информации об объектах системы [2, 4, 9].

Таким образом, концептуальная модель, представленная в соответствии со стандартом IDEF1X, является логической схемой базы данных для проектируемой системы.

Основными объектами концептуальной модели являются сущности и связи.

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

Правила для атрибутов сущности:

1. Каждый атрибут должен иметь уникальное имя.

2. Сущность может обладать любым количеством атрибутов.

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

4. Для каждого экземпляра сущности должно существовать значение каждого его атрибута (правило необращения в нуль - Not Null).

5. Ни один из экземпляров сущности не может обладать более чем одним значением для ее атрибута.

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

Стандарт IDEF1X описывает способы изображения двух типов сущностей - независимой и зависимой, и связей - идентифицирующих и неидентифицирующих (см. рис. 6.1).

Рис. 6.1.  Изображение сущностей и связей по стандарту IDEF1X

Каждая сущность может обладать любым количеством связей с другими сущностями.

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

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

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

Если сущность является зависимой, то связь ее с родительской сущностью называется идентифицирующей, в противном случае - неидентифицирующей.

Связь изображается на ER-диаграмме линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Идентифицирующая связь изображается сплошной линией, неидентифицирующая - пунктирной.

Связи дается имя, выражаемое грамматической формой глагола. Для связи дополнительно может присутствовать указание мощности: какое количество экземпляров сущности-потомка может существовать для сущности-родителя. Имя связи всегда формируется с точки зрения родителя, так что может быть образовано предложение, если соединить имя сущности родителя, имя связи, выражение мощности и имя сущности-потомка (например "много СТУДЕНТов - сдают - ЭКЗАМЕН").

Принципы изображения концептуальных моделей баз данных стандарта IDEF1 и IDEF1X используют CASE Studio и другие CASE-средства. Подобные системы позволяют на основе концептуальной модели генерировать физическую модель и программный код создания базы данных для большинства наиболее распространенных СУБД и серверов баз данных.

6.5. Пример описания модели данных информационной системы "Контингент студентов университета"

Первоначальный этап - создание текстового описания моделируемой системы.

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

Концептуальная модель базы данных

На концептуальном уровне данные информационной системы состоят из двух основных сущностей: "Студент" и "Успеваемость".

Минимальный состав атрибутов и их описание для сущности "Студент" представлены в табл. 6.1.

В табл. 6.2-6.5 представлены атрибуты сущностей "Успеваемость", "Факультет", "Специальность", "Предмет".

В физической модели каждой сущности будет соответствовать таблица базы данных, а каждому атрибуту - поле таблицы. Имена таблиц и полей лучше задавать с использованием латинских букв и достаточно короткими для удобства использования при программировании и для совместимости с системами, не использующими кириллицу. Состав данных и связи в концептуальной и физической моделях показаны в табл. 6.6 и табл. 6.7.