Курсовая ПрБД, 2 курс 3 семестр (для ИВТ и т.п.) / ПБД_метод к КР_v07[2024-2025]

МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

Федеральное государственное бюджетное образовательное учреждение высшего образования

«Поволжский государственный университет телекоммуникаций и информатики»

А.Р. Диязитдинова, Е.И. Горожанина

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

по выполнению курсовой работы «Проектирование реляционной базы данных» по дисциплине «Проектирование баз данных»

Учебно-методическое пособие

Самара, 2022 г.

УДК 681.3 Д509

Рекомендовано к изданию методическим советом ПГУТИ, протокол № 51 от 12.04.2022

Диязитдинова, А.Р.

Д509 Методические рекомендации по выполнению курсовой работы «Проектирование реляционной базы данных» по дисциплине «Проектирование баз данных»: учеб- но-методическое пособие / А.Р. Диязитдинова, Е.И. Горожанина – Самара: ФГБОУ ВО ПГУТИ, 2022. – 42 с.

Ил. 14. Библ. 7. Табл. 10

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

Предлагаемые методические указания предназначены для бакалавров очной формы обучения по направлениям подготовки/специальностям 02.03.03 – Математическое обеспечение и администрирование информационных систем, 09.03.01 – Информатика и вычислительная техника, 09.03.03 – Прикладная информатика, 09.03.04 – Программная инженерия.

©Диязитдинова, А.Р., 2022 ©Горожанина Е.И., 2022 ©ФГБОУ ВО ПГУТИ, 2022

2

3СОДЕРЖАНИЕ ПОЯСНИТЕЛЬНОЙ ЗАПИСКИ К КУРСОВОЙ

3

Введение

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

Задача проектирования БД является сложной по ряду причин:

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

−этап проектирования БД «пронизывает» все стадии ИТ-проекта, подвержен значительным корректировкам и заканчивается только в момент внедрения.

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

Самостоятельное выполнение курсовой работы подготавливает студента

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

−разработать инфологическую модель предметной области;

−спроектировать по ней реляционную базу данных;

−наполнить базу данных содержательной информацией;

−реализовать с помощью команд SQL все указанные в задании типы запросов.

1 Теоретические сведения о проектировании БД

1.1 Этапы проектирования БД

Данный этап начинается после проведения предпроектного анализа. Традиционно в процедуре проектирования БД выделяют три последо-

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

4

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

2)Логическое проектирование – развитие концептуальной схемы БД с учетом принимаемой модели (иерархической, сетевой, реляционной и т.д.).

3)Физическое проектирование – развитие логической схемы БД с учетом выбранной целевой СУБД.

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

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

Многие начинающие проектировщики БД недооценивают важность семантического моделирования. Зачастую это воспринимается как дополнительная

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

ипри эксплуатации, сопровождении и развитии уже заполненной БД.

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

1.2 Концептуальное проектирование БД

Целью концептуального проектирования является создание концептуальной схемы данных на основе представлений о предметной области каждого отдельного типа пользователей. Концептуальная схема представляет собой описание основных сущностей (таблиц) и связей между ними без учета принятой модели БД и синтаксиса целевой СУБД. Часто на такой схеме отображаются только имена сущностей (таблиц) без указания их атрибутов. Представление пользователя включает в себя данные, необходимые конкретному пользователю для принятия решений или выполнения некоторого задания. Концептуальная модель включает следующую последовательность шагов [1]:

5

1) Выделение сущностей

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

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

–синонимов (например, сотрудник и работник; ведомость и отчет);

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

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

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

–должна иметь уникальное имя, и к одному и тому же имени должна всегда применяться одна и та же интерпретация;

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

–иметь первичный ключ;

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

Например, для предметной области «Организация системы контроля доступа для предприятия» можно выделить следующие сущности: «Пользователь», «Пропуск», «Кабинет», «Считыватель» и пр. (Рис. 1).

Рис. 1. Примеры сущностей

2) Определение атрибутов

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

6

сущности или связи, задать себе вопрос «Какую информацию требуется хранить о …?».

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

–простой (атомарный, неделимый) – состоит из одного компонента с независимым существованием (например, «должность работника», «зарплата» и т.д.);

–составной (псевдоатомарный) – состоит из нескольких компонентов (например, «ФИО», «адрес» и т. д.). Степень атомарности атрибутов, закладываемая в модель, определяется разработчиком;

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

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

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

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

–неключевой (описательный);

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

После определения атрибутов задаются их домены (области допустимых значений), например:

–фамилия пользователя – набор из букв русского алфавита длиной не более 30 символов;

–пол – допустимые значения «М» (мужской) и «Ж» (женский). Задание доменов определяет набор допустимых значений для атрибута

(нескольких атрибутов), а также тип, размер и формат атрибута (атрибутов).

Например, для сущности «Пользователь» можно выделить атрибуты: (Рис. 2)

− Табельный номер – однозначный ЧИСЛО (10), обязательное поле;

7

−ФИО – псевдоатомарный (составной), ТЕКСТ (45), обязательный атрибут;

−Пол – однозначный ТЕКСТ или ЛОГИЧЕСКИЙ (1), необязательный атрибут;

−Дата рождения (однозначный) ДАТА, обязательный атрибут,

−Возраст – вычисляемый ЧИСЛО (2).

Рис. 2. Графическое изображение сущности и ее атрибутов

3) Определение ключей

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

–суперключ – атрибут или множество атрибутов, которое единственным образом идентифицирует экземпляр сущности;

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

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

–альтернативные ключ – потенциальные ключи, которые не выбраны в качестве первичного ключа.

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

8

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

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

–размер ключа в байтах должен быть как можно короче;

–тип домена ключа – числовой. При выборе символьных атрибутов в ключ часто возникают проблемы с вводом ошибочных значений;

–вероятность изменения значений ключа была наименьшей (например, «Номер пенсионного страхового свидетельства» более постоянный параметр, чем «Номер паспорта»).

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

Например, проанализировав атрибуты сущности «Пользователь», можно выделить два атрибута, претендующих на роль ключа – это «Табельный номер» и «ФИО». Рассмотрим сначала атрибут «ФИО»: гипотетически в компании могут работать два полных тезки, следовательно, данный атрибут не годится на роль ключа. Атрибут «Табельный номер» для каждого сотрудника является уникальным, следовательно, этот атрибут можно использовать в качестве первичного ключа.

4) Определение связей

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

–связи типа «часть–целое», определяемые обычно глаголами «состоит из», «включает» и т.п.;

–классифицирующие связи (например, «тип – подтип», «множество – элемент», «общее – частное» и т. п.);

–производственные связи (например, «начальник– подчиненный»);

9

–функциональные связи, определяемые обычно глаголами «производит», «влияет», «зависит от», «вычисляется по» и т. п.

Среди них выделяются только те связи, которые необходимы для удовлетворения требований к разработке БД.

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

–именем – указывается в виде глагола и определяет семантику (смысловую подоплеку) связи;

–кратностью (кардинальность, мощность): один-к-одному (1:1), один-ко-многим (1:N) и многие-ко-многим (N:M, N = M или N <> M). Кратность показывает, какое количество экземпляров одной сущности определяется экземпляром другой;

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

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

–степенью участия – количеством сущностей, участвующих в связи. В основном между сущностями существуют бинарные связи, т.е. ассоциации, связывающие две сущности (степень участия равна 2). Например, «Группа» включает «Студентов». В то же время по степени участия возможны следующие типы связей:

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

o тернарная – связывает три сущности. Например, «Студент» на «Сессии» получил «Оценку по дисциплине»;

o кватернарная и т.д.

10