МЕТОДИЧЕСКИЕ УКАЗАНИЯ К  КУРСОВОЙ РАБОТЕ

Цель работы:
?	освоение методики проектирования концептуальной инфор-мационной модели предметной области, преобразование концептуальной модели в физическую структуру базы данных (БД);
?	закрепление теоретических  знаний по курсу «Организация баз данных».
Задачи курсовой работы:
?	формализовать исходное описание предметной области;
?	построить концептуальную информационную модель, исполь-зуя  методику, изученную в рамках теоретического курса;
?	сгенерировать физическую структуру базы данных;
?	реализовать простое пользовательское приложение, демонст-рирующее накопленные студентом знания по курсу Организация БД.
Средства выполнения и форма отчетности: работа выполня-ется с использованием СУБД MS Access, клиентская часть может быть создана либо средствами СУБД, либо с помощью любых языков про-граммирования высокого уровня (Delphi, Visual Basic, Visual C и др.). Результат выполнения работы в виде пояснительной записки (отчета), подготовленной в среде MS WinWord, 

Таблица 2 ? Номера вариантов индивидуального задания

№	Название предметной области



3.		ВУЗ





Порядок выполнения работы:
1.	Создание концептуальной информационной модели пред-метной области.
Каждый студент получает  для работы предметную область (табл. 2).
Осуществляется формализация исходного описания в виде отно-шений с последующим их преобразованием и связывание в концепту-альную модель.
Процесс  проектирования сопровождается составлением ряда таблиц [1 (гл.6)], необходимыми пояснениями – обоснованиями прини-маемых решений.
Проектирование концептуальной модели предметной области  целесообразно производить с помощью специальных средств проекти-рования: BPWin, ERWin, Power Designer и др. При отсутствии данных инструментариев, проектирование концептуальной модели произво-дится вручную.
Разработка концептуальной модели данных основана на исполь-зовании трех основных конструктивных элементов для представления составляющих предметной области – сущностей, атрибутов и связей.
Сущности и атрибуты
Каждая сущность является множеством подобных индивидуаль-ных объектов, называемых экземплярами. Каждый экземпляр индиви-дуален и должен отличаться от всех остальных экземпляров. Атрибут выражает определенное свойство объекта. С точки зрения БД (физиче-ская модель), сущности соответствует таблица, экземпляру сущности – строка в таблице, а атрибуту – колонка таблицы.
Построение модели данных предполагает определение сущно-стей и атрибутов, т.е. необходимо определить, какая информация будет храниться в конкретной сущности или атрибуте. Сущность можно определить как объект, событие или концепцию, информация о которой должна сохраняться. Сущности должны иметь: наименование с четким смысловым значением, именоваться существительным в един-ственном лице, не носить «технических» наименований и быть достаточно важными для того, чтобы их моделировать. Именование сущности  в единственном числе облегчает в дальнейшем чтение модели. Фактически имя сущности дается по имени ее экземпляра.
Каждая сущность должна быть полностью определена с помо-щью текстового описания. Каждый атрибут хранит информацию об определенном свойстве сущности, а каждый экземпляр сущности должен быть уникальным. Атрибут или группа атрибутов, которые идентифицируют сущность, называется первичным ключом. При установлении связей между сущностями атрибуты первичного ключа родительской сущности мигрируют в качестве внешних ключей в дочернюю сущность.
Очень важно дать атрибуту правильное имя. Атрибуты должны именоваться в единственном числе и иметь четкое смысловое значе-ние. Соблюдение этого правила позволяет частично решить проблему нормализации данных уже на этапе определения атрибутов.
Связи
Связь является логическим соотношением между сущностями. Каждая связь должна именоваться глаголом или глагольной фразой. Имя связи выражает некоторое ограничение или бизнес-правило и об-легчает чтение построенной модели данных.
Различают зависимые и независимые сущности. Тип сущности определяется ее связью с другими сущностями. Идентифицирующая связь устанавливается между независимой (родительский конец связи) и зависимой (дочерний конец связи) сущностями. При установлении идентифицирующей связи атрибуты первичного ключа родительской сущности переносятся в состав первичного ключа дочерней сущности. Эта операция дополнения атрибутов дочерней сущности при создании связи называется миграцией атрибутов. В дочерней сущности атрибуты помечаются как внешний ключ (FK).
При установлении неидентифицирующей связи дочерняя сущ-ность остается независимой, а атрибуты первичного ключа родитель-ской сущности мигрируют в состав неключевых компонентов роди-тельской сущности. Не идентифицирующая связь служит для связыва-ния независимых сущностей. 
Имя связи – фраза, характеризующая отношение между родитель-ской и дочерней сущностями. Для связи один-ко-многим идентифици-рующей или не идентифицирующей достаточно указать имя, характе-ризующее отношение от родительской к дочерней сущности.
Тип связи (идентифицирующая/неидентифицирующая). Для не-идентифицирующей связи можно указать обязательность. В случае обязательной связи атрибут внешнего ключа получит признак NOT NULL, несмотря на то, что внешний ключ не войдет в состав первич-ного ключа дочерней сущности. В случае необязательной связи внеш-ний ключ может принимать значение NULL. Необязательная неиден-тифицирующая связь помечается прозрачным ромбиком со стороны родительской сущности.
Правила ссылочной целостности – логические конструкции, ко-торые выражают бизнес-правила использования данных и представляют собой правила вставки, замены и удаления. 
Информацию о предметной области суммируют составлением спецификаций по сущностям, атрибутам и отношениям с использова-нием графических диаграмм, в чем и заключается процесс моделиро-вания данных.
Основные этапы проектирования концептуальной модели:
1.	Первичный анализ информационных потребностей пользова-телей, выделение объектов предметной области и формирование ис-ходных отношений:
?	анализ информационных документов;
?	анализ конкретных информационных потребностей (запросов) пользователей.
2.	Проектирование исходных отношений:
?	определение атрибутов отношений и их типов данных;
?	нормализация отношений до 3 НФ.
3.	Связывание отношений в концептуальную информационную модель:
?	определение первичных ключей отношений;
?	определение связей между отношениями.
Ограничения концептуальной модели:
?	предметная область должна быть описана 8-10 взаимосвязан-ными отношениями;
?	каждое отношение должно содержать не менее 3 атрибутов;
?	в каждом отношении должен быть определен первичный ключ.
2.	Создание физической модели данных.
На основе спроектированной концептуальной модели создается физическая модель данных, свойственная для конкретной СУБД. 
При формировании физической модели определяются внешние ключи в связываемых отношениях. Добавляются промежуточные таб-лицы связи, с целью исключения связей «многие ко многим» (М:М).
Большинство автоматизированных средств проектирования по-зволяют произвести автоматическую генерацию физической модели на основе созданной концептуальной. При отсутствии таковых средств физическая модель создается вручную с последующим ее отражением в структурной части базы данных конкретной СУБД.

3.	Создание пользовательского приложения.
Приложение, работающее с созданной базой данных, должно обеспечивать выполнение следующих функций:
?	ввод информации в БД;
?	удаление информации из БД;
?	редактирование внесенной информации;
?	выборка данных по различным критериям; 
?	формирование отчетов и вывод информации из базы данных на экран и на принтер.
Ввод, замена и удаление информации должны производится в эк-ранных формах приложения.
4.	Оформление пояснительной записки (отчета).
Пояснительная записка к курсовому проекту должна включать: титульный лист, содержание, введение, основную часть, заключение, список использованных литературных источников, приложение.
Титульный лист оформляется согласно действующим стандар-там.
Введение должно содержать цель выполняемой курсовой работы, основные принципы, положенные в основу ее проведения, область применения.
В основной части должен быть отражен процесс и результат про-ектирования базы данных и пользовательского приложения. Основная часть должна содержать:
?	описание предметной области;
?	описание и обоснование выбранного средства реализации (СУБД, средства проектирования, программной среды написания при-ложения);
?	концептуальную информационную модель предметной облас-ти с полным описанием выделенных сущностей;
?	физическую модель базы данных;
?	описание пользовательского приложения.
Заключение должно содержать краткие выводы по результатам выполненной работы.
Список использованных литературных источников оформляется согласно действующим стандартам.
В приложении приводятся: экранные формы приложения, тексты SQL-запросов, создаваемых в приложении, и другая сопроводительная информация. 





РЕКОМЕНДУЕМАЯ ЛИТЕРАТУРА

1.	Кузнецов С.Д. Основы современных баз данных // Системы управления базами данных. – 1995. – №№ 1–5.
2.	Чудинов И.Л. Организация баз данных: Учебное пособие. –  Томск: ТУСУР, 2000. – 89 с.
3.	Матрин Дж. Организация баз данных в вычислительных сис-темах. – М: Мир, 1980.
4.	Атре Ш. Структурный подход к организации баз данных. – М.: Финансы и статистика, 1983.
5.	Дейт К.Дж. Введение в системы баз данных. – Киев, М.: Диа-лектика, 1998. – 784 с.
6.	Ульман Дж. Основы систем баз данных. – М.: Финансы и ста-тистика, 1983. 
7.	Пейдж, Вильям Дж., и др. Использование Oracle 8/8i. – М.: Из-дательский дом «Вильямс», 2000. – 1024 с.
8.	Саймон А.Р. Стратегические технологии баз данных: менедж-мент на 2000 год. – М.: Финансы и статистика, 1999. – 479 с.
9.	Системы баз данных третьего поколения: Манифест / Комитет по развитию функциональных возможностей СУБД // Системы управ-ления базами данных. – 1995. –№ 2.
10.	М. Аткинсон, Ф. Бансилон, Д. ДеВитт, К. Диттрих, Д. Майер, С. Здоник. Манифест систем объектно-ориентированных баз данных // Системы управления базами данных. – 1995. – № 4.
11.	Попов А.А. Программирование в среде СУБД FoxPro 2.0. По-строение систем обработки данных. – Киев: ТОО "ВЕК"; М.: Радио и связь, 1995. – 352 с.