Методические рекомендации по выполнению курсового проекта в рамках ПМ Разработка и администрирование баз данных
методическая разработка по теме

Трегубова Елена Сергеевна

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

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

Скачать:

ВложениеРазмер
Microsoft Office document icon mu_po_kursovomu_proektirovaniyu_mdk.02.02.doc587.5 КБ

Предварительный просмотр:

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

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

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

СРЕДНЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ МО

КРАСНОГОРСКИЙ ГОСУДАРСТВЕННЫЙ КОЛЛЕДЖ

Трегубова Е.С.

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ

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

по программе профессионального модуля

Разработка и администрирование баз данных

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

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

для специальности

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

Красногорск

2011


ОДОБРЕНЫ

На заседании отделения специальности 230115 Программирование в компьютерных системах

протокол № 2 от 30.08.2011г.


Заведующая отделением

________к.п.н. Е.С. Трегубова


          Утверждаю

Заместитель директора
по учебной работе

__________к.т.н. Е.В.Романова

Рассмотрены и рекомендованы к использованию в учебном процессе колледжа, на заседании Научно-методического совета колледжа, протокол

№ _____ от ________________ 2011г.


ВВЕДЕНИЕ

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

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

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

уметь:

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

знать:

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

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

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


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

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

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

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

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

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

2. Выбор темы

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

Допускается выполнение курсовой работы (проекта) по одной теме группой студентов.

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

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

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

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.  Проектирование базы данных фотоцентра.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- введение;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ТИПЫ ДЕТАЛЕЙ

Наименование

Изображение

Описание

Гайка

Шайба

Гвоздь

ДЕТАЛИ

Код детали

Название

Вес

Диаметр

Металл

Цвет

1

Гайка

20

50

Сталь

Серый

2

Шайба

50

30

Сплав №1

Черный

3

Гайка

31

45

Латунь

Желтый

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

ПОСТАВЩИКИ

Код пост

Фамилия И.О.

Страна

Город

Адрес

Телефон

Надежность

1

Орлов А.С.

Россия

Москва

Лесная 34-1-75

263-67-89

10

2

Станов О.Т.

Россия

Курск

Новая 23-56

23-45-12

35

3

Рыбаков И.И.

Украина

Ровно

Рыбная 2-34

34-54-12

15

ДЕТАЛИ

Код детали

Название

Вес

Диаметр

Металл

Цвет

1

Гайка

20

50

Сталь

Серый

2

Шайба

50

30

Сплав №1

Черный

3

Гайка

31

45

Латунь

Желтый

ПОСТАВКИ

Кто

Что

Сколько

Цена изделия

Цена доставки

Дата доставки

Оформлено

1

1

3000

234,56р.

4,56р.

29.10.03

да

2

3

4000

254,90р.

2,90р.

5.12.03

да

1

3

23000

294,00р.

4,00р.

12.01.04

нет

3

2

1200

136,58р.

6,58р.

20.11.03

да

2

2

45000

504,77р.

5,77р.

15.11.03

да

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ТИП МЕБЕЛИ

Наименование

Описание

Диван

Стол

Стул

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

Код предмета

Тип

Модель

Описание

Изображение

Стоимость

1

Диван

Колибри

2

Стол

Прима

3

Диван

Увертюра

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

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

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

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

ТИП ДЕТАЛЕЙ

Наименование

Изображение

Описание

Гайка

Шайба

Гвоздь

ДЕТАЛИ

Код детали

Тип

Вес

Диаметр

Металл

Цвет

1

Гайка

20

50

Сталь

Серый

2

Шайба

50

30

Сплав №1

Черный

3

Гайка

31

45

Латунь

Желтый

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

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

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

ПОСТАВЩИКИ

Код пост

Фамилия И.О.

Страна

Город

Адрес

Телефон

Надежность

1

Орлов А.С.

Россия

Москва

Лесная 34-1-75

263-67-89

10

2

Станов О.Т.

Россия

Курск

Новая 23-56

23-45-12

35

3

Рыбаков И.И.

Украина

Ровно

Рыбная 2-34

34-54-12

15

ДЕТАЛИ

Код детали

Тип

Вес

Диаметр

Металл

Цвет

1

Гайка

20

50

Сталь

Серый

2

Шайба

50

30

Сплав №1

Черный

3

Гайка

31

45

Латунь

Желтый

ПОСТАВКИ

Кто

Что

Сколько

Цена изделия

Цена доставки

Дата доставки

Оформлено

1

1

3000

234,56р.

4,56р.

29.10.03

да

2

3

4000

254,90р.

2,90р.

5.12.03

да

1

3

23000

294,00р.

4,00р.

12.01.04

нет

3

2

1200

136,58р.

6,58р.

20.11.03

да

2

2

45000

504,77р.

5,77р.

15.11.03

да

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

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

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

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

Код предмета

Тип

Модель

Описание

Изображение

Стоимость

1

Диван

Колибри

2

Стол

Прима

3

Диван

Увертюра

ДЕТАЛИ

Код детали

Тип

Вес

Диаметр

Металл

Цвет

1

Гайка

20

50

Сталь

Серый

2

Шайба

50

30

Сплав №1

Черный

3

Гайка

31

45

Латунь

Желтый

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

Где

Что

Сколько

1

1

12

2

3

4

1

3

12

3

2

6

2

2

8

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Номер

Название

Кол-во стр.

Тираж

Дата

Фамилия

Адрес

Телефон

№счета

1

«Городок»

263

50000

15.03.02

Орлов А.С.

Москва

345-67-89

25348217632

2

«Ранним утром»

450

30000

10.09.03

Станов О.Т.

Курск

34-23-78

56487392028

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

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

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

Автор

Номер автора

Фамилия И.О.

Адрес

Телефон

№счета

1

Орлов А.С.

Москва, Лесная 34-1-75

263-67-89

21436587

2

Станов О.Т.

Курск, Новая 23-56

23-45-12

65748392

3

Рыбаков И.И.

Казань, Рыбная 2-34

34-54-12

98765430

4

Туманов П.Р.

Москва, Стасовой 6-2-56

943-45-89

23894567

...

Книга

Номер книги

Название

Кол-во страниц

Тираж

Дата выхода

Автор

1

«Городок»

263

50000

15.03.2002

1

2

«Ранним утром»

450

30000

10.09.2003

2

3

«Рыжий»

341

45000

25.05.2002

4

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

Автор

Номер автора

Фамилия И.О.

Адрес

Телефон

№счета

1

Орлов А.С.

Москва, Лесная 34-1-75

263-67-89

21436587

2

Станов О.Т.

Курск, Новая 23-56

23-45-12

65748392

3

Рыбаков И.И.

Казань, Рыбная 2-34

34-54-12

98765430

Книга

Номер книги

Название

Кол-во страниц

Тираж

Дата выхода

1

«Городок»

263

50000

15.03.2002

2

«Ранним утром»

450

30000

10.09.2003

3

«Рыжий»

341

45000

25.05.2002

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

Номер книги

Номер автора

Верстка

1

3

да

2

1

нет

3

2

нет

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

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

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

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

либо такая:

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

Автор

Номер автора

Фамилия И.О.

Адрес

Телефон

№счета

1

Орлов А.С.

Москва, Лесная 34-1-75

263-67-89

21436587

2

Станов О.Т.

Курск, Новая 23-56

23-45-12

65748392

3

Рыбаков И.И.

Казань, Рыбная 2-34

34-54-12

98765430

4

Туманов П.Р.

Москва, Стасовой 6-2-56

943-45-89

23894567

...

Книга

Номер книги

Название

Кол-во страниц

Тираж

Дата выхода

Автор

1

«Городок»

263

50000

15.03.2002

1

2

«Ранним утром»

450

30000

10.09.2003

2

3

«Рыжий»

341

45000

25.05.2002

4

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

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

и

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

Автор

Номер автора

Фамилия И.О.

Адрес

Телефон

№счета

1

Орлов А.С.

Москва, Лесная 34-1-75

263-67-89

21436587

2

Станов О.Т.

Курск, Новая 23-56

23-45-12

65748392

3

Рыбаков И.И.

Казань, Рыбная 2-34

34-54-12

98765430

Книга

Номер книги

Название

Кол-во страниц

Тираж

Дата выхода

1

«Городок»

263

50000

15.03.2002

2

«Ранним утром»

450

30000

10.09.2003

3

«Рыжий»

341

45000

25.05.2002

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

Номер книги

Номер автора

Верстка

1

3

да

2

1

нет

3

2

нет

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

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

Автор

Номер автора

Фамилия И.О.

Адрес

Телефон

№счета

1

Орлов А.С.

Москва, Лесная 34-1-75

263-67-89

21436587

2

Станов О.Т.

Курск, Новая 23-56

23-45-12

65748392

3

Рыбаков И.И.

Казань, Рыбная 2-34

34-54-12

98765430

Книга

Номер книги

Название

Кол-во страниц

Тираж

Дата выхода

1

«Городок»

263

50000

15.03.2002

2

«Ранним утром»

450

30000

10.09.2003

3

«Рыжий»

341

45000

25.05.2002

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

Номер книги

Номер автора

Верстка

1

3

да

2

1

нет

3

2

нет

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

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

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

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

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

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

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

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

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

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

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

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

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

Необходимый уровень подготовки

Уровень катания лыжника

Условия для free ride

Условия для helliski

Код

  Страна                                                                                                                                                                                                                                                                                

Название

Въезд в страну

Время перелета

Разница во времени

Валюта

Телефонный код

Отель

Название

Регион катания

Расстояние до подъемника

Звездность

Регион катания

Название

Страна

Перепад высот

Легкие трассы (зеленые)

Средние трассы (синие)

Сложные трассы (красные)

Трассы для экспертов (черные)

Снежные пушки

Для беговых лыж

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

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

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

           

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

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

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

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

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

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

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

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

СТРАНА

Название

Время перелета

Разница во времени

Валюта

Телефонный код

Въезд в страну

Австрия

3 часа

Франция

3,5 – 4 часа

Андорра

3,5 часа

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

Название

Страна

Перепад высот

Легкие трассы

Средние трассы

Сложные трассы

для экспертов

Снежные пушки

Для беговых лыж

Ле дез Альп

Франция

1650-3568м

Три долины

Франция

1350-2450м

Обертауэрн

Австрия

1740-2305м

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

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

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

Название

Страна

Перепад высот

Легкие трассы

Средние трассы

Сложные трассы

для экспертов

Снежные пушки

Для беговых лыж

Ле дез Альп

Франция

1650-3568м

Три долины

Франция

1350-2450м

Обертауэрн

Австрия

1740-2305м

ОТЕЛЬ

Название

регион катания

удаленность

от подъемника

звездность

Hotel Latini

Шюттдорф

Alpina

Гармиш-Партенкирхен

Coray

Энкамп

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

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

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

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

Название

Страна

Перепад высот

Легкие трассы

Средние трассы

Сложные трассы

для экспертов

Снежные пушки

Для беговых лыж

Ле дез Альп

Франция

1650-3568м

Три долины

Франция

1350-2450м

Обертауэрн

Австрия

1740-2305м

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

Код

Уровень катания лыжника

free ride

helliski

1

начинающий

-

2

средний

+

3

средний

-

КУДА ЕХАТЬ

Регион катания

Уровень

Примерная стоимость тура

Энкамп

3

Солдеу

1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ЧИТАТЕЛЬ

N_чит_бил

ДатаЗаписи

Фамилия

Имя

Отчество

ГодРожд

СоцСтатус

ГородПроживания

Тел_дом

Тел_моб

РАЗДЕЛ

КодРаздела

Название

КНИГА

КодКниги

Заголовок

Заголовок_ин

КодРаздела

ЯзыкОригинала

N_изд

Место_Изд

Издательство

Год_изд

Кол_стр

Илл

Серия

Кол_Экз_В_Библ

ЯЗЫК

КодЯзыка

НазваниеЯзыка

автор

КодАвтора

ФИО_Автора_рус

ФИО_Автора_ин

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

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

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

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

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

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

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

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

АВТОРЫ И ИХ КНИГИ (издание)

КодКнАвт

Автор

Книга

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

а)

б)

         

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

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

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

ФОРМУЛЯР

Код

КодЧитателя

КодИздания

ДатаВыдачи

ФактДатаВозврата

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

а)

б)

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

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

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

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

Язык

КодЯзыка

Язык

1

рус.

2

нем.

3

англ.

Раздел

КодРаздела

Название

1

Литературно-художественное издание

2

Научно-популярное издание

3

Учебник

4

Учебное пособие

5

Издание по изобразительному искусству

6

Справочное издание

Книга

КодКниги

Заголовок

Заголовок_ин

КодРаздела

язык оригинала

N_Изд

Место_Изд

Издательство

Год_изд

Кол_Стр

Илл

Серия

Кол_Экз_В_Библ

10

Новый сладостный стиль.Роман.

Литературно-художественное издание

рус.

М.

ИзографЪ, ЭКСМО

2005

624

Нет

3

11

Десятилетие клеветы (радиодневник писателя)

Литературно-художественное издание

рус.

М.

ИзографЪ, ЭКСМО

2004

416

Нет

3

12

Самоучитель работы на компьютере

Учебник

рус.

8

СПб.

Питер

2005

655

Да

2

13

Самоучитель работы на компьютере

Учебник

рус.

3

М.

Нолидж

1996

484

Да

1

14

17

Патриот: Фантастический роман.

Jingo

Литературно-художественное издание

англ.

1

М.

ЭКСМО

2005

560

Нет

Плоский мир

1

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

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

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

Авторы и их книги

КодКнАвт

Автор

Книга

11

Пратчетт Т.

Роковая музыка

12

Пратчетт Т.

Патриот: Фантастический роман.

13

Аксенов В.П.

Десятилетие клеветы (радиодневник писателя)

14

Аксенов В.П.

Новый сладостный стиль.Роман.

15

Левин А.Ш.

Самоучитель работы на компьютере

20

Левин А.Ш.

Самоучитель работы на компьютере

21

Рубина Д.

Несколько торопливых слов любви… Повесть и рассказы

22

Рубина Д.

Несколько торопливых слов любви… Повесть и рассказы

23

Энде М.

Джим Пуговка и Чертова Дюжина: Повесть-сказка.

24

Бекаревич Ю.Б.

СУБД Access для Windows 95 в примерах.

25

Пушкина Н.В.

СУБД Access для Windows 95 в примерах.

26

Баш Е.Г.

Справочник по русскому языку для студентов-иностранцев

Автор

КодАвтора

ФИО_Автора_рус

ФИО_Автора_ин

11

Левин А.Ш.

12

Аксенов В.П.

13

Рубина Д.

14

Пратчетт Т.

Pratchett Terry

15

Энде М.

Ende Michael

16

Бекаревич Ю.Б.

17

Пушкина Н.В.

18

Баш Е.Г.

Книга

КодКниги

Заголовок

Заголовок_ин

КодРаздела

язык оригинала

N_Изд

Место_Изд

Издательство

Год_изд

Кол_Стр

Илл

Серия

Кол_Экз_В_Библ

10

Новый сладостный стиль.Роман.

Литературно-художественное издание

рус.

М.

ИзографЪ, ЭКСМО

2005

624

Нет

3

11

Десятилетие клеветы (радиодневник писателя)

Литературно-художественное издание

рус.

М.

ИзографЪ, ЭКСМО

2004

416

Нет

3

..

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

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

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

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

Формуляр

Код

КодЧитателя

КодИздания

ДатаВыдачи

ФактДатаВозврата

3

1204

21

03.02.2005

01.03.2005

4

5877

20

04.06.2005

02.07.2005

5

8088

11

22.05.2005

Авторы и их книги

КодКнАвт

Автор

Книга

11

Пратчетт Т.

Роковая музыка

12

Пратчетт Т.

Патриот: Фантастический роман.

Читатель

N_чит_бил

ДатаЗаписи

Фамилия

Имя

Отчество

ГодРожд

СоцСтатус

ГородПроживания

Адрес

Тел_дом

Тел_моб

1204

12.05.1986

Иванова

Светлана

Петровна

10.05.1939

пенсионер

Москва

ул. Тверская, д.15, кв.87

380-90-12

5877

22.01.2004

Ремизов

Алексей

Михайлович

11.04.1990

учащийся

Москва

ул. Садово-Кудринская, д.12, кв.124

921-19-59

8(916)123-34-34

8088

01.04.1998

Александров

Петр

Петрович

09.09.1962

служащий

Зеленоград

ул. Маяковского, д.2, кв.5

11-12-13

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


Приложение 1

министерствО образования МО
ГОСУДАРСТВЕННОЕ БЮДЖЕТНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

СРЕДНЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ МО

КРАСНОГОРСКИЙ ГОСУДАРСТВЕННЫЙ КОЛЛЕДЖ

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

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

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

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

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

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

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

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

         ___________ (подпись)

                                                                     

                                                             

Проверил:

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

____________________________

________________ (подпись)

Дата______________

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

___________ Е.С. Трегубова

Дата_____________

Сдан в архив_____________

Красногорск

2013

Литература

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


По теме: методические разработки, презентации и конспекты

Методические рекомендации по выполнению курсового проекта по дисциплине: "Микропроцессоры и микропроцессорные системы"

Методические рекомендации по выполнению курсового проекта по дисциплине: "Микропроцессоры и микропроцессорные системы"Используется интегрированная среда разработки программного обеспечения Visual DSP+...

Методические рекомендации по выполнению курсового проекта для специальности 230401 по ПМ.02 Участие в разработке информационных систем МДК02.01 ИТ и платформы разработки ИС

Курсовое проектирование проводится в рамках МДК 02.01 "Информационные системы и платформы разработки информационных систем" по специальности 230401 Информационные системы.Курсовое проектирование...

Методические рекомендации по выполнению курсового проекта по ПМ 02. "Разработка и администрирование баз данных"

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

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

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОГО ПРОЕКТА ПМ 03 Технническое обслуживание и ремонт компьютерных систем и комплексов для студентов заочной формы обучения специальности Компьютерные сист...

Методические рекомендации по выполнению курсового проекта МДК.01.02 Техническое обслуживание и ремонт автомобильного транспорта

Методические рекомендации  составлены в соответствии с рабочей программой по ПМ.01 Техническое обслуживание и ремонт  автотранспорта.Основной целью  методических рекомендаций  явля...

МЕТОДИЧЕСКИЕ РЕКОМЕНДАЦИИ ПО ВЫПОЛНЕНИЮ КУРСОВОГО ПРОЕКТА по разработке информационной системы на платформе 1С:Предприятие для специальностей 09.02.04 «Информационные системы (по отраслям)», 09.02.05 «Прикладная информатика (по отраслям)»

Методические рекомендации содержат структуру, цели, задачи и требования к выполнению курсового проекта по разработке информационной системы на платформе 1С:Предприятие. Рекомендации предназначены для ...

Методические рекомендации для выполнения курсового проекта ПМ.02 «Выполнение технологических процессов при строительстве, эксплуатации и реконструкции строительных объектов» МДК.02.01 «Организация технологических процессов при строительстве, эксплуатации

Методические  рекомендации по выполнению курсового  проекта  являются частью программы подготовки специалистов среднего звена  в соответствии с ФГОС по специальности 08.02.01...