Методические указания по выполнению курсового проектирования
учебно-методический материал на тему

МИНИСТЕРСТВО ОБРАЗОВАНИЯ МОСКОВСКОЙ ОБЛАСТИ

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ

УЧРЕЖДЕНИЕ СРЕДНЕГО ПРОФЕСИИОНАЛЬНОГО

ОБРАЗОВАНИЯ МОСКОВСКОЙ ОБЛАСТИ

"КРАСНОГОРСКИЙ КОЛЛЕДЖ"

МЕТОДИЧЕСКИЕ УКАЗАНИЯ

ПО ВЫПОЛНЕНИЮ КУРСОВОГО ПРОЕКТА

по МДК 02.02 ТЕХНОЛОГИЯ РАЗРАБОТКИ И

ЗАЩИТЫ БАЗ ДАННЫХ

ПМ.02 РАЗРАБОТКА И АДМИНИСТРИРОВАНИЕ БАЗ ДАННЫХ

основной профессиональной образовательной программы (ОПОП)

для специальности СПО 09.02.03 (230115)

Программирование в компьютерных системах

Красногорск

2014

Методические указания по выполнению курсового проекта по профессиональному модулю ПМ. 02 Разработка и администрирование баз данных разработаны на основе программы профессионального модуля и Федерального государственного образовательного стандарта среднего профессионального образования по специальности 09.02.03 (230115) «Программирование в компьютерных системах», квалификация – техник-программист.

Организация-разработчик: Государственное бюджетное образовательное учреждение среднего профессионального образования Московской области «Красногорский колледж».

Разработчики:

Трегубова Елена Сергеевна – к.п.н., преподаватель высшей категории ГБОУ СПО МО «Красногорский колледж».

Рецензент:

Простяков Сергей Иванович – инженер программист НТЦ ОАО «Красногорский завод им. С.А. Зверева»

ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

В соответствии с федеральным государственным образовательным стандартом среднего профессионального образования III поколения к минимуму содержания и уровню подготовки выпускников по специальности 09.02.03 (230115) “Программирование в компьютерных системах” в ходе освоения профессионального модуля студент должен:

иметь практический опыт:

• работы с объектами базы данных в конкретной системе управления базами данных;
• использования средств заполнения базы данных;
• использования стандартных методов защиты объектов базы данных;

уметь:

• создавать объекты баз данных в современных системах управления базами данных и управлять доступом к этим объектам;
• работать с современными сase-средствами проектирования баз данных;
• формировать и настраивать схему базы данных;
• разрабатывать прикладные программы с использованием языка SQL;
• создавать хранимые процедуры и триггеры на базах данных;
• применять стандартные методы для защиты объектов базы данных;

знать:

• основные положения теории баз данных, хранилищ данных, баз знаний;
• основные принципы построения концептуальной, логической и физической модели данных;
• современные инструментальные средства разработки схемы базы данных;
• методы описания схем баз данных в современных системах управления базами данных (СУБД);
• структуры данных СУБД, общий подход к организации представлений, таблиц, индексов и кластеров;
• методы организации целостности данных;
• способы контроля доступа к данным и управления привилегиями;
• основные методы и средства защиты данных в базах данных;
• модели и структуры информационных систем;
• основные типы сетевых топологий, приемы работы в компьютерных сетях;
• информационные ресурсы компьютерных сетей;
• технологии передачи и обмена данными в компьютерных сетях;
• основы разработки приложений баз данных

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

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

Данные методические указания содержат общие требования и рекомендации к курсовому проектированию для студентов специальности 09.02.03 (230115) «Программирование в компьютерных системах».

Цель и задачи курсового проектирования

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

Выполнение студентом курсового проекта проводится с целью:

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

Задачами курсового проекта являются:

• изучение особенностей конкретной предметной области, относящихся к теме курсового проекта (работы);
• анализ возможных подходов и методов решения с обоснованием выбранного метода;
• выбор или разработка модели (математической, структурной, информационной и т.д.), необходимой для достижения цели;
• выбор эффективных алгоритмов с учётом их точности, устойчивости, сходимости и т.д.;
• разработка базы данных и приложений к ней;
• анализ полученных результатов работы БД;
• разработка программной и эксплуатационной документации.

Выбор темы

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

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

Темы курсовых проектов

Темы курсовых проектов можно разбить на несколько групп:

1. Проектирование баз данных для конкретных предметных областей.

2. Сравнительный анализ возможностей СУБД.

3. Сравнительный анализ средств автоматизации проектировании БД.

4. Научно – исследовательские темы по любому из направлений по тематике «Базы данных».

Основной группой курсовых проектов является «Проектирование баз данных для конкретных предметных областей». Ниже приведены примеры возможных тем:

1.   Проектирование БД для работника склада (варианты: склад торговой организации, занимающейся сбытом как продукции собственного производства, так и продукции внешних поставщиков; склад оптовой торговой организации; склад готовой продукции; склад сырья и материалов и др.)

2.   Проектирование БД для контроля выполнения нагрузки преподавателей ВУЗа.

3.   Проектирование БД для контроля сессионной успеваемости студентов ВУЗа.

4.   Проектирование БД для учета контингента студентов ВУЗа.

5.   Проектирование БД для организации дипломного проектирования в ВУЗе.

6.   Проектирование БД для организации курсового проектирования.

7.   Проектирование БД для профкома ВУЗа.

8.   Проектирование БД для начисления стипендии в ВУЗе.

9.   Проектирование БД для библиотеки ВуЗа.

10.  Проектирование БД для управления работой компьютерных аудиторий учебного заведения.

11.  Проектирование БД для управления работой класса свободного доступа.

12.  Проектирование БД для начисления заработной платы преподавателей.

13.  Проектирование базы данных Ученого совета по защите диссертаций.

14.  Проектирование базы данных Отдела аспирантуры.

15.  Проектирование БД для контроля успеваемости школьников.

16.  Проектирование БД детского сада.

17.  Проектирование БД спортивной школы.

18.  Проектирование БД центра детского творчества.

19.  Проектирование БД партнеров софтверной фирмы.

20.  Проектирование БД коммерческого учебного центра.

21.  Проектирование БД для расчета заработной платы (варианты: преподавателей ВУЗа, всех сотрудников ВУЗа, предприятий /организаций с разными системами оплаты труда).

22.  Проектирование БД для учета домашних финансов.

23.  Проектирование БД для домашней библиотеки.

24.  Проектирование БД для районной библиотеки.

25.  Проектирование БД для домашней видеотеки.

26.  Проектирование БД для пункта проката видеофильмов.

27.  Проектирование БД кинотеатра.

28.  Проектирование БД драматического театра.

29.  Проектирование БД для домашней аудиотеки.

30.  Проектирование БД тренера спортивной команды.

31.  Проектирование БД агентства по аренде квартир.

32.  Проектирование БД риэлтерского агентства.

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

34.  Проектирование БД для автосервисной фирмы.

35.  Проектирование БД для автозаправочной станции.

36.  Проектирование БД центра по продаже автомобилей.

37.  Проектирование БД таксомоторного парка.

38.  Проектирование БД по подсистеме «Кадры» (варианты: для ВУЗа, школы, промышленного предприятия, торговой фирмы, софтверной фирмы и т.п.).

39.  Проектирование БД службы знакомств.

40.  Проектирование базы данных туристического агентства.

41.  Проектирование базы данных туристического оператора.

42.  Проектирование базы данных туристического клуба.

43.  Проектирование БД районной поликлиники. Подсистема «Работа с пациентами».

44.  Проектирование БД районной поликлиники. Подсистема «Учет льготных лекарств».

45.  Проектирование БД районной поликлиники. Подсистема «Планирование и учет работы медицинского персонала».

46.  Проектирование БД районной поликлиники. Подсистема «Учет пациентов».

47.  Проектирование базы данных родильного дома.

48.  Проектирование базы данных больницы. Подсистема «Работа с пациентами».

49.  Проектирование базы данных больницы. Подсистема «Лекарственное обеспечение».

50.  Проектирование базы данных аптеки.

51.  Проектирование базы данных гостиницы. Подсистема «Работа с клиентами».

52.  Проектирование базы данных дачного кооператива.

53.  Проектирование базы данных Издательства. Подсистема «Работа с авторами».

54.  Проектирование базы данных Издательства. Подсистема «Служба маркетинга».

55.  Проектирование базы данных Учета расчетов с клиентами в банке.

56.  Проектирование базы данных строительной фирмы.

57.  Проектирование базы данных городской телефонной сети. Подсистема «Учет расчетов с клиентами».

58.  Проектирование базы данных торговой организации.

59.  Проектирование базы данных аэропорта.

60.  Проектирование базы данных ГИБДД.

61.  Проектирование базы данных фотоцентра.

Помимо выше приведенных тем студенты могут предложить свою предметную область.

Содержание и этапы выполнения курсового проекта

Курсовые проекты по любой из категории тем обязательно должны включать проектную часть, выполненную на компьютере с использованием той или иной СУБД. Для выполнения курсового проекта может быть выбрана любая СУБД.

Основной группой курсовых проектов является «Проектирование баз данных для конкретных предметных областей». Курсовые проекты этой группы должны содержать следующие разделы:

1. Описание предметной области. Постановка задачи.
2. Выбор средств/методологии проектирования. Выбор СУБД.
3. Построение инфологической (концептуальной) модели предметной области.
4. Проектирование логической структуры БД.
5. Выявление полного перечня ограниченной целостности, присущего данной предметной области. Определение перечня ограничений целостности, которые будут контролироваться в данном КП. Выбор способа реализации контроля целостности для каждого из ограничений.
6. Проектирование физической структуры базы данных.
7. Организация ввода данных в БД.
8. Организация корректировки БД.
9. Реализация запросов, получение отчетов.
10. Разработка интерфейса.
11. Реализация проекта в среде конкретной СУБД.
12. Оформление проекта.
13. Защита.

Раздел «Описание предметной области. Постановка задачи» должен содержать всю необходимую и достаточную информацию для проектирования Базы данных. Прежде всего, должен быть определен круг лиц, который будет иметь доступ к базе данных, их права и обязанности, описаны бизнес-процессы, происходящие в предметной области, приведены формы всех входных и выходных документов, описаны регламентированные запросы, определена периодичность решения всех задач. Также должны быть описаны алгоритмы получения промежуточных и результатных показателей, изображен граф взаимосвязей показателей.

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

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

Описывая любую организацию, надо оговорить, допустимо или нет внутреннее совместительство.

Описывая предметную область, надо знать действующее законодательство. Эта информация позволит определить, какие свойства необходимо определить для объекта, а также выявить ограничения целостности. Так, например, на дневное отделение в вузы можно принимать лиц, не достигших 35 лет. Стипендию можно выплачивать, если студент получает первое образование. Есть ограничения на минимально допустимую зарплату, на минимальный возраст, с которого можно принимать на работу.

В разделе «Выбор средств/методологии проектирования. Выбор СУБД» должна быть выбрана методика проектирования базы данных. СУБД также может быть выбрана любая. Степень подробности описания тех средств, которые рассматриваются при выборе, зависит от того, насколько средства, используемые при анализе, распространены. Если они известны и охарактеризованы в используемой в учебном процессе литературе, то подробно описывать их не надо, необходимо просто обосновать свой выбор. В противном случае описание должно быть более подробным.

В разделе «Построение инфологической (концептуальной) модели предметной области» надо построить ER-модель. Рекомендуется сначала построить базовую ER-модель, а затем ER-модель в среде любой CASE-системы.

Содержание раздела «Проектирование логической структуры базы данных» будет зависеть от выбранной СУБД, методики проектирования и, если используются средства автоматизации проектирования, особенностей выбранного средства проектирования. Если алгоритм проектирования логической структуры базы данных многовариантный, то необходимо мотивировать выбор варианта. Кроме того, на этапе логического проектирования необходимо определить типы и длины полей. В данном разделе должна быть распечатана созданная схема базы данных.

Выявление полного перечня ограничений целостности, присущего данной предметной области, осуществляется, во-первых, на основе информации, приведенной в разделе «Описание предметной области». Далее должны быть определить ограничения целостности, вызванные особенностями используемой СУБД. Не все выявленные ограничения должны контролироваться в БД. Необходимо определить перечень ограничений целостности, которые будут контролироваться в данном КП. Далее необходимо выбрать способ реализации контроля целостности для каждого из ограничений. Необходимо не просто описать этот способ, но и привести соответствующие распечатки, отражающие их реализацию в конкретной системе.

Проектирование физической структуры базы данных существенно зависит от выбранной СУБД.

В разделе «Организация ввода данных в БД» должны быть разработаны экранные формы ввода данных. Организация корректировки БД может потребовать разработку специальных форм для выполнения тех или иных видов корректировки.

В разделе «Реализация запросов, получение отчетов» необходимо реализовать запросы и получить отчеты, описанные в разделе «Описание предметной области».

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

Работа спроектированной системы должна быть опробована на контрольном примере.

Структура курсового проекта

По содержанию курсовой проект должен носить практический или опытно-экспериментальный характер.

Курсовой проект должен включать оттестированную базу данных и пояснительную записку (не менее 20 листов формата А4). В зависимости от темы курсового проекта может быть включена графическая часть.

Пояснительная записка курсового проекта (работы) должна иметь следующую структуру:

- титульный лист установленного образца (Приложение 1);

- содержание;

- введение;

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

- описательная часть разработанной базы данных (Приложение 2);

- заключение, в котором делаются выводы и рекомендации относительно возможностей использования материалов проекта;

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

- приложения.

Во введении кратко раскрывается актуальность и значение темы, формулируется цель и задачи проекта (работы).

Заключение включает основные выводы и перспективы дальнейшего развития защищаемого ПО.

В список литературы, с указанием библиографических данных, включается литература, используемая автором курсового проекта при разработке ПО. Если в работе сделаны ссылки на научную информацию, позволяющую принять конкретное решение, включение в список литературы первоисточника обязательно. При использовании формул, взятых из библиографического источника, ссылка на источник обязательна. Список литературы составляется в алфавитном порядке авторов.

В приложения могут включаться следующие материалы:

• таблицы БД;
• схемы межтабличных связей, структур баз данных и т.п.;
• интерфейсные формы  к БД, образцы отчетов, запросов, используемых в БД.

В графической части курсового проекта могут быть представлены следующие результаты:

• структурная схема разрабатываемой предметной области;
• концептуальная схема БД;
• логическая схема БД, ER – модель;
• физическая схема БД.

Объем графической части может составлять 3 – 5 листов формата А1 для проекта (работы).

Оформление пояснительной записки к курсовому проекту

По объему курсовой проект должен быть не менее 15 – 20 страниц печатного текста. Шрифт текста – Times New Roman, размер шрифта – 14 пт, междустрочный интервал – полуторный. В списке литературы не менее 5 источников.

Пояснительная записка к курсовому проекту печатается на принтере на листах писчей бумаги формата А4 (210 × 297 мм). Для разворотных таблиц и рисунков допускается формат А3 (297 × 420 мм). Заголовки таблиц, названия схем допускается печатать через одинарный интервал.

Напечатанный текст должен иметь поля следующих размеров:

• верхние и нижние – 25 мм;
• правые - 10 мм;
• левые – 25 мм.

Абзацный отступ (“красная строка”) равен 1,25 мм. Заголовки глав отделяются от текста сверху двойным интервалом (т.е. двумя пустыми строками), снизу – одинарным интервалом. Заголовки параграфов отделяются от текста одинарным интервалом (т.е. одной пустой строкой).

Основной текст печатается строчными (маленькими) буквами, заглавными буквами (прописными, большими) печатаются аббревиатуры, а также слова “ВВЕДЕНИЕ”, “ЗАКЛЮЧЕНИЕ” и “ПРИЛОЖЕНИЕ”, которые располагаются по центру листа. Названия глав печатаются полужирным начертанием шрифта.

В тексте должна быть соблюдена соподчинённость глав, параграфов и пунктов. Нумерация глав и параграфов выполняется арабскими цифрами, которые отделяются от названий точкой; номер параграфа состоит из цифры, обозначающей номер главы, и цифры обозначающей его порядковый номер в составе главы, отделённых друг от друга точкой. Знак § не ставится. Если параграфы состоят из нумерованных пунктов, их нумерация состоит из трёх разделённых точками цифр.

Нумерация таблиц и рисунков сквозная или разбитая по главам (локальная, номер рисунка - последняя цифра, первая цифра - номер главы, если же глава разбита на разделы, то номер главы и через точку, номер раздела).

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

Каждая глава пояснительной записки к курсовому проекту начинается с новой страницы

Страницы пояснительной записки нумеруются от титульного листа и до последнего, цифра 1 на титульном листе не ставится. Нумерация страниц выполняется арабскими цифрами внутри штампа.

Приложения нумеруются арабскими цифрами (без значка №) и должны иметь названия.

Пояснительная записка к курсовому проекту должна быть переплетена или заключена в папку.

Защита курсового проекта

После полного завершения курсового проекта происходит его защита.

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

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

Критериями оценки курсового проекта являются:

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

Окончательная оценка курсового проекта выставляется по итогам защиты и качеству работы.

Курсовой проект должен быть защищен до сдачи экзамена по междисциплинарному курсу «Технология разработки и защиты баз данных». Студены, не сдавшие курсовые проекты или получившие на защите неудовлетворительные оценки, не допускаются к очередным экзаменам.

Защищенные курсовые проекты студентам не возвращаются и хранятся в архиве учебного заведения.

Литература

1. ГОСТ 7.1–84. Библиографическое описание документа. Общие требования и правила составления.
2. ГОСТ 7.9-95. Реферат и аннотация. Общие Требования.
3. Диго С.М. Базы данных: учебное пособие. М.:МЭСИ, 2012. – 157с.
4. Киреева О.А. Базы данных: учебное пособие. Тольятти: Изд-во ТГУС, 2013. – 136с.
5. Кузьмина С.П. Базы данных: учебное пособие. СПб.: СПбГИЭУ, 2012. – 189с.
6. Кумскова И.А. Базы данных. – М.: Логус, 2014. – 462с.
7. Шишкин В.В. Методические указания к курсовому проекту. – Смоленск, 2010.

Приложение 1

МИНИСТЕРСТВО ОБРАЗОВАНИЯ МОСКОВСКОЙ ОБЛАСТИ

ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ ОБРАЗОВАТЕЛЬНОЕ

УЧРЕЖДЕНИЕ СРЕДНЕГО ПРОФЕСИИОНАЛЬНОГО

ОБРАЗОВАНИЯ МОСКОВСКОЙ ОБЛАСТИ

"КРАСНОГОРСКИЙ КОЛЛЕДЖ"

Специальность 09.02.03 (230115)

«Программирование в компьютерных системах»

КУРСОВОЙ ПРОЕКТ

по междисциплинарному курсу МДК.02.02

 «Технология разработки и защиты баз данных»

Пояснительная записка на тему:

«Разработка базы данных для библиотеки колледжа»

Выполнил студент  гр.№22П-13к                                                                Плинский Павел Александрович

         ___________ (подпись)

Проверил:

преподаватель

____________________________

________________ (подпись)

Дата______________

Зав.отделением

___________ /_____________/

Дата_____________

Сдан в архив_____________

г. Красногорск

2014

Приложение 2 Описательная часть разработанной базы данных 

База данных «Фонотека»

Требуется создать базу данных фонотеки. В этой базе заказчик хотел бы хранить информацию

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

Некоторые условия работы фонотеки, существенные для проектирования базы данных:

• в фонотеке может быть несколько различных дисков одного исполнителя
• бывают диски-сборники
• каждый клиент может взять в фонотеке несколько различных дисков

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

Этапы проектирования базы данных:

1. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
2. определение атрибутов каждой сущности
3. выявление связей между сущностями
4. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
5. построение ER-диаграмм, отображающих выявленные связи
6. формирование таблиц базы данных по ER-диаграммам:

• определение нужного количества таблиц
• определение первичных и вторичных ключей таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

• выявленные объекты
• их атрибуты
• связи между объектами
• классы принадлежности (с обоснованием принятых решений)
• соответствующие ER-диаграммы
• описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1.        создание описания таблиц (обычно в режиме конструктора)

2. создание схемы базы данных
3. создание форм, удобных для ввода данных в таблицу
4. создание кнопочной формы-заставки
5. заполнение таблиц (с использованием форм)

Этапы реализации приложения к базе данных в Delphi / C++

1. создание удобных и понятных форм интерфейса приложения к базе данных

1. создание собственных переменных, процедур и функций
2. создание формы-заставки приложения
3. заполнение базы данных

Форма отчета: распечатанный курсовой проект, сброшюрованный в папку А4, и CD-диск с записанным электронным приложением, базой данных, и текстового документа курсового проекта.

8. Примеры предметных областей для написания курсового проекта

База данных «Фонотека»

Требуется создать базу данных фонотеки. В этой базе заказчик хотел бы хранить информацию

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

Некоторые условия работы фонотеки, существенные для проектирования базы данных:

• в фонотеке может быть несколько различных дисков одного исполнителя
• бывают диски-сборники
• каждый клиент может взять в фонотеке несколько различных дисков

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

Этапы проектирования базы данных:

7. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
8. определение атрибутов каждой сущности
9. выявление связей между сущностями
10. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
11. построение ER-диаграмм, отображающих выявленные связи
12. формирование таблиц базы данных по ER-диаграммам:

• определение нужного количества таблиц
• определение первичных и вторичных ключей таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

• выявленные объекты
• их атрибуты
• связи между объектами
• классы принадлежности (с обоснованием принятых решений)
• соответствующие ER-диаграммы
• описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1.        создание описания таблиц (обычно в режиме конструктора)

6. создание схемы базы данных
7. создание форм, удобных для ввода данных в таблицу
8. создание кнопочной формы-заставки
9. заполнение таблиц (с использованием форм)

Форма отчета: показ на машине всех элементов созданной базы данных.

База данных «Турфирма»

Требуется создать базу данных для небольшой туристической фирмы. В этой базе заказчик хотел бы хранить информацию

• о странах, в которые фирма организует туры
• о наличии конкретных туров в данный момент
• о клиентах, обслуживаемых фирмой

Некоторые условия работы туристической фирмы, существенные для проектирования базы данных:

• каждый тур – в одну страну (но, конечно, может быть несколько различных туров в одну страну)
• на каждый клиент может заказать несколько туров (в одну или разные страны; для себя или для кого-то другого).

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

Этапы проектирования базы данных:

13. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
14. определение атрибутов каждой сущности
15. выявление связей между объектами
16. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
17. построение ER-диаграмм, отображающих выявленные связи
18. формирование таблиц базы данных по ER-диаграммам:

• определение нужного количества таблиц
• определение первичных и вторичных ключей таблиц
• определение атрибутов для всех таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

• выявленные объекты
• их атрибуты
• связи между объектами
• классы принадлежности (с обоснованием принятых решений)
• соответствующие ER-диаграммы
• описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1.        создание описания таблиц (обычно в режиме конструктора)

10. создание схемы базы данных
11. создание форм, удобных для ввода данных в таблицу
12. создание кнопочной формы-заставки
13. заполнение таблиц (с использованием форм)

Форма отчета: показ на машине всех элементов созданной базы данных.

База данных «Строительное управление»

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

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

Некоторые условия работы строительного управления, существенные для проектирования базы данных:

• каждый строитель имеет несколько специальностей
• на одном объекте может работать много строителей
• в каждый конкретный момент каждый строитель работает на одном объекте.

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

Этапы проектирования базы данных:

19. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
20. определение атрибутов каждой сущности
21. выявление связей между сущностями
22. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
23. построение ER-диаграмм, отображающих выявленные связи
24. формирование таблиц базы данных по ER-диаграммам:

• определение нужного количества таблиц
• определение первичных и вторичных ключей таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

• выявленные объекты
• их атрибуты
• связи между объектами
• классы принадлежности (с обоснованием принятых решений)
• соответствующие ER-диаграммы
• описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1.        создание описания таблиц (обычно в режиме конструктора)

14. создание схемы базы данных
15. создание форм, удобных для ввода данных в таблицу
16. создание кнопочной формы-заставки
17. заполнение таблиц (с использованием форм)

Отчет: показ на машине всех элементов созданной базы данных.

Проектирование БД «Поставки деталей»

В этой базе заказчик хотел бы хранить информацию

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

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

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

Этапы проектирования базы данных:

25. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
26. определение атрибутов каждой сущности
27. выявление связей между сущностями
28. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
29. построение ER-диаграмм, отображающих выявленные связи
30. формирование таблиц базы данных по ER-диаграммам:

• определение нужного количества таблиц
• определение первичных и вторичных ключей таблиц

1 и 2 этапы: объекты, их атрибуты и первичные ключи

Список объектов (сущностей): типы деталей, детали, поставщики

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

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

3, 4 и 5 этапы:  выявление степени связей и классов принадлежности, их фиксация с помощью диаграмм

В этой диаграмме отражено правило: «каждая деталь – это деталь одного определенного типа;  возможна поставка нескольких деталей одного типа, но с разными характеристиками»; в базе данных допускается информация о типах деталей, которые еще не поставляются, но «бестиповых» деталей не бывает.

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

6 этап:  формирование таблиц базы данных по ER-диаграммам

В  связи ТИПЫ ДЕТАЛЕЙ --- ДЕТАЛИ  степень связи «один-ко-многим», n-связная сущность  имеет обязательный класс принадлежности => в соответствии с ER-методом достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.

Но у нас в таблице ДЕТАЛИ уже есть такой атрибут – Название (он и будет  вторичным ключом, соответствующим первичному ключу Наименование).

ТИПЫ ДЕТАЛЕЙ

ДЕТАЛИ

В связи ДЕТАЛИ --- ПОСТАВЩИКИ степень связи «многие-ко-многим». В этом случае классы принадлежности сущностей не влияют на количество и структуру соответствующих таблиц => необходимо формирование трех таблиц – по одной для каждой сущности (ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы), а также таблицы для связи. Таблица, создаваемая для связи, должна иметь по одному ключу от каждой сущности.

ПОСТАВЩИКИ

ДЕТАЛИ

ПОСТАВКИ

Проектирование БД «Производство мебели»

В этой базе заказчик хотел бы хранить информацию

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

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

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

Этапы проектирования базы данных:

31. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
32. определение атрибутов каждой сущности, первичных ключей
33. выявление связей между сущностями
34. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
35. построение ER-диаграмм, отображающих выявленные связи
36. формирование таблиц базы данных по ER-диаграммам:

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

1 и 2 этапы: объекты, их атрибуты и первичные ключи

Список объектов (сущностей): 

• тип мебели
• предметы мебели
• тип деталей
• детали
• поставщики

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

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

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

3, 4 и 5 этапы:  выявление степени связей и классов принадлежности, их фиксация с помощью диаграмм

В этой диаграмме отражены свойства связи двух объектов нашей предметной области (типа мебели и предмета мебели):

• может производиться много различных предметов мебели одного типа (например, много различных диванов)
• каждый предмет мебели – это мебель одного определенного типа
• в базе не будет храниться информация о типах мебели, которая не производится мебельным комбинатом

В этой диаграмме отражены следующие свойства связи двух других объектов нашей предметной области (типа детали и деталей):

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

Свойства связи двух объектов нашей предметной области (деталей и поставщиков) таковы:

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

6 этап:  формирование таблиц базы данных по ER-диаграммам

В  связи сущностей ТИП МЕБЕЛИ   ⇔   ПРЕДМЕТЫ МЕБЕЛИ  степень связи «один-ко-многим», n-связная сущность имеет обязательный класс принадлежности; следовательно, в соответствии с ER-методом

достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.

Но у нас в таблице ПРЕДМЕТЫ МЕБЕЛИ уже есть такой атрибут – Тип (он и будет  вторичным ключом, соответствующим первичному ключу Наименование).

ТИП МЕБЕЛИ

ПРЕДМЕТЫ МЕБЕЛИ

Итак, через первичный ключ Наименование в таблице ТИП МЕБЕЛИ и вторичный ключ Тип в таблице ПРЕДМЕТЫ МЕБЕЛИ будет фиксироваться связь двух сущностей нашей предметной области – ТИПА МЕБЕЛИ и ПРЕДМЕТОВ МЕБЕЛИ.

Аналогично, в связи сущностей ТИП ДЕТАЛЕЙ   ⇔   ДЕТАЛИ  степень связи «один-ко-многим», n-связная сущность  имеет обязательный класс принадлежности; следовательно, в соответствии с ER-методом

достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.

Но у нас в таблице ДЕТАЛИ уже есть такой атрибут – Тип (он и будет  вторичным ключом, соответствующим первичному ключу Наименование).

ТИП ДЕТАЛЕЙ

ДЕТАЛИ

Итак, через первичный ключ Наименование в таблице ТИП ДЕТАЛЕЙ и вторичный ключ Тип в таблице ДЕТАЛИ будет фиксироваться связь двух сущностей нашей предметной области – ТИПА ДЕТАЛЕЙ и ДЕТАЛЕЙ.

В связи сущностей ДЕТАЛИ  ⇔  ПОСТАВЩИКИ степень связи «многие-ко-многим». В этом случае классы принадлежности сущностей не влияют на количество и структуру соответствующих таблиц; следовательно,

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

ПОСТАВЩИКИ

ДЕТАЛИ

ПОСТАВКИ

В таблице-связке ПОСТАВКИ поле Кто является вторичным ключом, соответствующим первичному ключу Код поставщика таблицы ПОСТАВЩИКИ; поле Что является вторичным ключом, соответствующим первичному ключу Код детали таблицы ДЕТАЛИ. С помощью этих вторичных ключей фиксируется связь сущностей ДЕТАЛИ и ПОСТАВЩИКИ. Дополнительные поля в таблице ПОСТАВКИ могут использоваться для уточнения характеристик этой связи.

В связи сущностей ДЕТАЛИ  ⇔  ПРЕДМЕТЫ МЕБЕЛИ степень связи «многие-ко-многим». В этом случае классы принадлежности сущностей не влияют на количество и структуру соответствующих таблиц; следовательно,

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

ПРЕДМЕТЫ МЕБЕЛИ

ДЕТАЛИ

ИСПОЛЬЗОВАНИЕ ДЕТАЛЕЙ

Поле Где является вторичным ключом, соответствующим первичному ключу Код предмета таблицы ПРЕДМЕТЫ МЕБЕЛИ; поле Что является вторичным ключом, соответствующим первичному ключу Код детали таблицы ДЕТАЛИ. Таким образом, в таблице-связке ИСПОЛЬЗОВАНИЕ ДЕТАЛЕЙ с помощью двух вторичных ключей Где и Что отражена связь сущностей ПРЕДМЕТЫ МЕБЕЛИ и ДЕТАЛИ. Поле Сколько уточняет одно из свойств этой связи – количество деталей, используемых в производстве конкретного предмета мебели.

Таким образом, проектирование базы данных «Производство мебели» завершено.

База данных «Лесничество»

Требуется создать базу данных для небольшого лесничества. В этой базе заказчик хотел бы хранить информацию

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

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

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

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

Этапы проектирования базы данных:

37. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
38. определение атрибутов каждой сущности
39. выявление связей между сущностями
40. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
41. построение ER-диаграмм, отображающих выявленные связи
42. формирование таблиц базы данных по ER-диаграммам:

• определение нужного количества таблиц
• определение первичных и вторичных ключей таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

• выявленные объекты
• их атрибуты
• связи между объектами
• классы принадлежности (с обоснованием принятых решений)
• соответствующие ER-диаграммы
• описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1. создание описания таблиц (обычно в режиме конструктора)
2. создание схемы базы данных
3. создание форм, удобных для ввода данных в таблицу
4. создание кнопочной формы-заставки
5. заполнение таблиц (с использованием форм)

Форма отчета: показ на машине всех элементов созданной базы данных.

База данных «Библиотека»

Требуется создать базу данных библиотеки. В этой базе заказчик хотел бы хранить информацию

• о книгах, которые есть в этой библиотеке, и о том, к какому разделу относится каждая книга
• об авторах, чьи книги есть в этой библиотеке
• о читателях, которые берут книги в этой библиотеке

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

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

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

Этапы проектирования базы данных:

43. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
44. определение атрибутов каждой сущности
45. выявление связей между сущностями
46. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
47. построение ER-диаграмм, отображающих выявленные связи
48. формирование таблиц базы данных по ER-диаграммам:

• определение нужного количества таблиц
• определение первичных и вторичных ключей таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

• выявленные объекты
• их атрибуты
• связи между объектами
• классы принадлежности (с обоснованием принятых решений)
• соответствующие ER-диаграммы
• описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1.        создание описания таблиц (обычно в режиме конструктора)

18. создание схемы базы данных
19. создание форм, удобных для ввода данных в таблицу
20. создание кнопочной формы-заставки
21. заполнение таблиц (с использованием форм)

Форма отчета: показ на машине всех элементов созданной базы данных.

База данных «Автопарк»

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

• о том, какие водители на каких маршрутах могут работать (т.е. знают эти маршруты)
• о наличии и состоянии подвижного состава автобусного парка
• о том, какие автобусы закреплены за какими водителями

Некоторые условия работы автобусного парка, существенные для проектирования базы данных:

• каждый водитель может знать несколько маршрутов; каждый маршрут обслуживается несколькими водителями
• один автобус может быть закреплен за несколькими водителями; но каждый водитель всегда ездит на одном и том же автобусе (хотя, возможно, по разным маршрутам).

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

Этапы проектирования базы данных:

49. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
50. определение атрибутов каждой сущности
51. выявление связей между сущностями
52. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
53. построение ER-диаграмм, отображающих выявленные связи
54. формирование таблиц базы данных по ER-диаграммам:

• определение нужного количества таблиц
• определение первичных и вторичных ключей таблиц

Форма отчета: должны быть представлены все материалы, полученные на каждом (!с первого по шестой!) этапе проектирования базы данных, т.е.

• выявленные объекты
• их атрибуты
• связи между объектами
• классы принадлежности (с обоснованием принятых решений)
• соответствующие ER-диаграммы
• описание разработанных таблиц (с обоснованием создания именно такого количества таблиц и указанием их первичных и вторичных ключей)

Этапы реализации базы данных в Access:

1. создание описания таблиц (обычно в режиме конструктора)
2. создание схемы базы данных
3. создание форм, удобных для ввода данных в таблицу
4. создание кнопочной формы-заставки
5. заполнение таблиц (с использованием форм)

Отчет: показ на машине всех элементов созданной базы данных.

Краткое описание ER–метода проектирования реляционных баз данных

( метод, использующий схему «сущность-связь» -«Entity-Relationship» )

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

ОПРЕДЕЛЕНИЯ:

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

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

Связь – это некоторая ассоциация между двумя сущностями.

Атрибут – это свойство сущности.

Сущность – это, как правило, существительное; связь чаще всего выражается глаголом.

Например, проектируется база данных издательства, предназначенная для хранения информации о книгах и авторах, которые их написали. Тогда два главных объекта (две сущности, информация о которых должна быть отражена в базе данных) – это книга и автор. Эти сущности содержательно соединены с помощью связи пишет. Атрибуты сущности книга – это название, количество страниц, тираж, дата выхода сигнального экземпляра, цена и т.д. Атрибуты сущности автор – это фамилия, адрес, телефон, №счета и т.д.

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

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

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

В нашем примере в качестве ключевого атрибута сущности АВТОР было решено взять фамилию, а в качестве ключевого атрибута сущности КНИГА взять её название. Первое решение заведомо не является бесспорным: возможно появление авторов-однофамильцев (тогда атрибут Фамилия И.О. теряет уникальность и не может быть использован в качестве ключа). В принципе, допустимо появление книг с одинаковыми названиями.

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

Если окажется, что ни один содержательный атрибут не может быть использован как ключевой, то существует (по меньшей мере) два способа решения этой проблемы:

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

Для нашего примера выберем второй способ:

Связь между двумя сущностями может быть представлена графически в виде ER-диаграммы:

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

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

Связь ОДИН-К-ОДНОМУ:

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

Если все экземпляры сущности должны участвовать в связи, то участие называется обязательным, и изображается на ER-диаграмме кружком, помещенным в блок, изображающий сущность (при словесной формулировке такой связи обычно используется глагол «должен»):

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

Если не все экземпляры сущности должны участвовать в связи, то участие называется необязательным, и кружок на ER-диаграмме располагается вне блока сущности (при словесной формулировке такой связи обычно используется глагол «может»):

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

Для сущностей АВТОР - КНИГА возможны еще два типа связи один-к-одному, отражающих два оставшихся варианта обязательности включения экземпляров:

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

 «Каждый автор пишет не более одной книги, и каждая книга пишется не более чем одним автором», т.е. в базе данных допускается наличие авторов, не пишущих сейчас ни одной книги, и наличие книг, которые еще никто не пишет.

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

Связь ОДИН-КО -МНОГИМ:

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

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

Следующая диаграмма отражает связь один-ко-многим сущностей АВТОР – КНИГА, где экземпляры обеих сущностей вступают в обязательную связь:

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

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

Для сущностей АВТОР - КНИГА возможны еще два типа связи один-ко-многим, отражающих два оставшихся варианта обязательности включения экземпляров:

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

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

Аналогично анализируются и фиксируются все варианты связи один-ко-многим сущностей КНИГА - АВТОР (с учетом обязательности / необязательности участия в связи всех экземпляров этих сущностей).

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

Связь МНОГИЕ-КО -МНОГИМ:

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

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

Следующая диаграмма отражает связь многие-ко-многим сущностей АВТОР – КНИГА, где экземпляры обеих сущностей вступают в обязательную связь:

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

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

Для сущностей АВТОР - КНИГА возможны еще два типа связи многие-ко-многим, отражающих два оставшихся варианта обязательности включения экземпляров:

«Каждую книгу может писать несколько авторов; каждый автор может писать несколько книг (но должен писать хотя бы одну)», т.е. в базе данных не будет информации об авторах, которые не пишут ни одной книги, но допускается хранить информацию о книгах, которые еще никто не пишет.

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

Правила генерации таблиц по ER-диаграмме

Связь ОДИН-К-ОДНОМУ:

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

Пусть в нашем примере между сущностями АВТОР и КНИГА выявлена такая связь:

Тогда в базе данных будет только одна таблица, отображающая свойства этих сущностей:

План издательства

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

Пусть в нашем примере между сущностями АВТОР и КНИГА выявлена такая связь:

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

Автор

Книга

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

Автор

Книга

План издательства

Связь ОДИН-КО-МНОГИМ:

Замечание: в этом случае определяющим фактором является класс принадлежности n-связной сущности; класс принадлежности 1-связной сущности на конечный результат не влияет.

Правило 1: Если класс принадлежности n-связной сущности является обязательным, то достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.

Пусть в нашем примере между сущностями АВТОР и КНИГА выявлена такая связь:

либо такая:

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

Автор

Книга

Правило 2: Если класс принадлежности n-связной сущности не является обязательным, то необходимо формирование трех таблиц – по одной для каждой сущности (ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы), а также таблицы для связи. Таблица, создаваемая для связи, должна иметь по одному ключу от каждой сущности.

Таким образом, для ситуаций

и

необходимо три таблицы: по одной для каждой сущности и таблица-связка:

Автор

Книга

План издательства

Связь МНОГИЕ-КО-МНОГИМ:

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

Автор

Книга

План издательства

Проектирование БД «Зимний отдых с ДжетТревел»

В этой базе заказчик хотел бы хранить информацию:

• о различных странах (Австрия, Германия, Италия, Франция, Швейцария, Андорра и т.п.)
• о различных регионах катания (например, различные курорты одной страны, количестве легких и сложных трасс, наличии снежных пушек и условий для беговых лыж)
• об отелях
• о необходимом уровне подготовки путешественника (включая возможности занятия freeride, helliski)

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

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

Этапы проектирования базы данных:

55. определение объектов (сущностей) предметной области - источников данных, которые должны быть включены в базу данных
56. определение атрибутов каждой сущности, первичных ключей
57. выявление связей между сущностями
58. определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь
59. построение ER-диаграмм, отображающих выявленные связи
60. формирование таблиц базы данных по ER-диаграммам:

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

1 и 2 этапы: объекты, их атрибуты и первичные ключи

Список объектов (сущностей): 

• страна
• регион катания
• трассы
• отель

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

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

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

3, 4 и 5 этапы:  выявление степени связей и классов принадлежности, их фиксация с помощью диаграмм

В этой диаграмме отражены свойства связи двух объектов нашей предметной области (страна и регион катания):

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

В этой диаграмме отражены свойства связи двух объектов нашей предметной области (регион катания и необходимый уровень подготовки):

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

В этой диаграмме отражены свойства связи двух объектов нашей предметной области (регион катания и отель):

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

6 этап:  формирование таблиц базы данных по ER-диаграммам

В  связи сущностей СТРАНА   ⇔   РЕГИОН КАТАНИЯ    и   РЕГИОН КАТАНИЯ    ⇔  ОТЕЛЬ степень связи «один-ко-многим», n-связная сущность имеет обязательный класс принадлежности; следовательно, в соответствии с ER-методом

достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.

Но у нас в таблице РЕГИОН КАТАНИЯ уже есть такой атрибут – Страна (он и будет  вторичным ключом, соответствующим первичному ключу Название).

СТРАНА

РЕГИОН КАТАНИЯ

Итак, через первичный ключ Название в таблице СТРАНА и вторичный ключ Страна в таблице РЕГИОН КАТАНИЯ будет фиксироваться связь двух сущностей нашей предметной области –СТРАНЫ и РЕГИОНА КАТАНИЯ.

У нас в таблице ОТЕЛЬ уже есть такой атрибут – Регион катания (он и будет  вторичным ключом, соответствующим первичному ключу Название).

РЕГИОН КАТАНИЯ

ОТЕЛЬ

Итак, через первичный ключ Название в таблице РЕГИОН КАТАНИЯ и вторичный ключ Регион катания в таблице ОТЕЛЬ будет фиксироваться связь двух сущностей нашей предметной области –ОТЕЛЯ и РЕГИОНА КАТАНИЯ.

В связи сущностей РЕГИОН КАТАНИЯ  ⇔  НЕОБХОДИМЫЙ УРОВЕНЬ ПОДГОТОВКИ степень связи «многие-ко-многим». В этом случае классы принадлежности сущностей не влияют на количество и структуру соответствующих таблиц; следовательно,

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

РЕГИОН КАТАНИЯ

НЕОБХОДИМЫЙ УРОВЕНЬ ПОДГОТОВКИ

КУДА ЕХАТЬ

В таблице-связке КУДА ЕХАТЬ поле Регион катания является вторичным ключом, соответствующим первичному ключу Название таблицы РЕГИОН КАТАНИЯ; поле Уровень является вторичным ключом, соответствующим первичному ключу Код таблицы НЕОБХОДИМЫЙ УРОВЕНЬ ПОДГОТОВКИ. С помощью этих вторичных ключей фиксируется связь сущностей РЕГИОН КАТАНИЯ и НЕОБХОДИМЫЙ УРОВЕНЬ ПОДГОТОВКИ. Дополнительные поля в таблице КУДА ЕХАТЬ могут использоваться для уточнения характеристик этой связи – примерная стоимость тура на человека на неделю.

Проектирование БД « Районная библиотека»

В этой базе заказчик хотел бы хранить информацию:

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

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

• каждая книга принадлежит какому-то разделу; может быть много книг, относящихся к одному разделу; возможен раздел, в котором нет книг
• в библиотеке может быть много книг одного автора; могут быть книги, у которых несколько авторов.
• каждый читатель может взять в библиотеке несколько книг; читатель может не брать книги какое-то время; читатель может брать книги на срок не более 1 месяца – потом он должен их продлить или по возвращении книг заплатить штраф из расчета 5 руб. за 1 просроченный день.
• каждая книга была написана на каком-либо языке; может быть много книг, у которых язык оригинала один и тот же; нет сведений о языках оригинала, на которых не написано ни одной книги.

Этапы проектирования базы данных:

1. Определение объектов (сущностей) предметной области – источников данных, которые должны быть включены в базу данных.
2. Определение атрибутов каждой сущности, первичных ключей.
3. Выявление связей между сущностями.
4. Определение степени каждой выделенной связи (один-к-одному, один-ко-многим, многие-ко-многим) и класса принадлежности каждой сущности, который характеризует обязательность включения каждого экземпляра сущности в связь.
5. Построение ER-диаграмм, отображающих выявленные связи.
6. формирование таблиц базы данных по ER-диаграммам:

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

1 и 2 этапы: объекты, их атрибуты и первичные ключи

Список объектов (сущностей): 

• автор
• раздел
• книга
• язык оригинала
• читатель
• формуляр
• авторы и их книги (издание)

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

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

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

3, 4 и 5 этапы:  выявление степени связей и классов принадлежности, их фиксация с помощью диаграмм

В этой диаграмме отражены свойства связи двух объектов нашей предметной области (книги и разделы):

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

В этой диаграмме отражены свойства связи двух объектов нашей предметной области (язык и книга):

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

В этой диаграмме отражены свойства связи двух объектов нашей предметной области (авторы и книги):

• в библиотеке может быть много книг одного автора;
• могут быть книги, у которых много авторов.
• в базе не будет храниться информация о книгах и авторах, которых нет в фонде библиотеки.

многозначные связи не могут непосредственно реализоваться в реляционной базе данных, поэтому необходимо внедрить дополнительный объект-связку АВТОРЫ И ИХ КНИГИ (ИЗДАНИЕ)  как совокупность данных об авторах и написанных ими книгах – возвращение ко 2-му этапу. Атрибуты данной сущности:

Тогда получаем новые диаграммы:

а)

б)

В этой диаграмме отражены свойства связи двух объектов нашей предметной области (читатель и издание):

• каждый читатель может взять в библиотеке несколько изданий;
• читатель может не брать издания какое-то время;
• могут быть издания, которые не взял ни один читатель;
• читатель может брать издания на срок не более 1 месяца – потом он должен их продлить или по возвращении издания заплатить штраф из расчета 5 руб. за 1 просроченный день.

Много-многозначные связи не могут непосредственно реализоваться в реляционной базе данных, поэтому необходимо внедрить дополнительный объект-связку ФОРМУЛЯР  как совокупность данных об изданиях и читателях – возвращение ко 2-му этапу. Атрибуты данной сущности:

Тогда получаем новые диаграммы:

а)

б)

6 этап:  формирование таблиц базы данных по ER-диаграммам

В  связи сущностей КНИГА   ⇔   РАЗДЕЛ    и   КНИГА   ⇔  ЯЗЫК степень связи «один-ко-многим», n-связная сущность имеет обязательный класс принадлежности; следовательно, в соответствии с ER-методом

достаточно использовать две таблицы (по одной для каждой сущности); ключ каждой сущности служит в качестве первичного ключа соответствующей таблицы. Кроме того, ключ 1-связной сущности должен быть добавлен как атрибут в таблицу, представляющую n-связную сущность.

Но у нас в таблице КНИГА уже есть такие атрибуты – КодРаздела (вторичный ключ, соответствующий одноименному первичному ключу таблицы РАЗДЕЛ) и ЯзыкОригинала (соответствует ключу КодЯзыка таблицы ЯЗЫК).

В связи сущностей КНИГА  ⇔  АВТОР степень связи «многие-ко-многим». В этом случае классы принадлежности сущностей не влияют на количество и структуру соответствующих таблиц; следовательно,

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

Такой таблицей станет АВТОРЫ И ИХ КНИГИ  (ИЗДАНИЕ)

В этой таблице поле Автор является вторичным ключом, соответствующим первичному ключу КодАвтора таблицы АВТОР; поле Книга является вторичным ключом, соответствующим первичному ключу КодКниги таблицы КНИГА. С помощью этих вторичных ключей фиксируется связь сущностей КНИГА и АВТОР.

В связи сущностей  АВТОРЫ И ИХ КНИГИ  (ИЗДАНИЕ) ⇔  ЧИТАТЕЛЬ степень связи «многие-ко-многим». В этом случае классы принадлежности сущностей не влияют на количество и структуру соответствующих таблиц; следовательно,

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

Такой таблицей станет ФОРМУЛЯР: