
- •230102.65 «Автоматизированные системы обработки информации и управления» и
- •Введение
- •1. Цели и задачи курсового проектирования
- •2. Тематика и содержание курсовых проектов
- •3. Задания по курсовому проектированию
- •4. Правила оформления пояснительной записки
- •Введение;
- •Заключение;
- •Приложения.
- •5. Методика курсового проектирования
- •5.1. Техническое задание на разработку базы данных
- •5.2. Введение
- •5.3. Описание предметной области и анализ требований к базе данных
- •5.4. Моделирование базы данных
- •5.4.1. Концептуальная модель предметной области
- •5.4.3. Диаграмма функциональных зависимостей
- •5.4.4. Физическая модель базы данных
- •5.6. Разработка интерфейса пользователя
- •5.7. Заключение
- •5.8. Приложения
- •7. Порядок выполнения курсового проекта (работы)
- •7. Порядок защиты курсового проекта (работы)
- •8. Пример титульного листа
- •9. Пример технического задания
- •10. Список рекомендуемой литературы
- •Библиографический список
5.4. Моделирование базы данных
Данная часть представляет собой описание всех этапов моделирования и разработки базы данных в соответствии с вариантом предметной области, ее описанием, системной спецификацией и техническим заданием. Здесь последовательно приводятся все этапы моделирования баз данных: концептуальная модель предметной области, ER-диаграмма и физическая модель базы данных. Самой важной целью моделирования является создание структурированной непротиворечивой интерпретации материальных объектов и реально существующей информации в рамках предметной области, а также выработка правил их взаимодействия [5].
5.4.1. Концептуальная модель предметной области
Концептуальная модель представляет собой логическую схему, связанную с представлением данных в контексте их взаимосвязей с другими данными. Основными объектами данной модели являются:
Сущность – экземпляр типа сущности, который может быть идентифицирован уникальным образом [5];
Связь – некоторая осмысленная ассоциация между сущностями различных типов [5].
Каждая сущность имеет набор свойств – атрибутов, значения которых однозначно характеризуют интерпретацию материального объекта реального мира. Каждая сущность должна иметь как минимум один атрибут с уникальными значениями, который будет являться первичным ключом. Любой атрибут может являться внешним ключом и использоваться для организации связей между сущностями, но на практике, за незначительным исключением, используются атрибуты с числовыми значениями.
Концептуальная модель строится на основании описания предметной области и представляет собой набор таблиц, каждая из которых описывает одну из сущностей (табл. 2). В таблицах указывается порядковый номер и имя атрибута, которое должно быть уникальным в рамках сущности, его участие в организации ключа, множество возможных значений и описание, в котором указываются особенности использования атрибута и комментарии. В названии таблицы указывается имя сущности. В поле «Ключ» может содержаться одно или несколько значений из множества {PK, FK, CK}, которое определяет отношение атрибута к ключам:
PK (от англ. primary key – первичный ключ) – атрибут является первичным ключом, однозначно идентифицирующим экземпляры сущности;
FK (от англ. foreign key – внешний ключ) – атрибут является внешним ключом, т.е. соответствует потенциальному ключу некоторого отношения [5]. Используется для организации связи;
CK (от англ. composite key – составной ключ) – атрибут является частью составного ключа.
Таблица 2. Сущность «Студент»
№ |
Имя атрибута |
Ключ |
Значение |
Описание |
1 |
Номер студенческого билета |
PK |
Положительное число, либо набор символов длиной не более 8. |
Первичный ключ. Используется для организации связей. |
2 |
Ф.И.О. студента |
|
Текстовое поле. Длина не более 256 символов |
|
3 |
Дата рождения |
|
Дата в формате ДД.ММ.ГГГГ |
|
… |
… |
… |
… |
… |
N |
|
|
|
|
5.4.2. ER-диаграмма базы данных
На основании концептуальной модели строится ER-диаграмма базы данных, которая представляет собой схему, содержащую сущности и их атрибуты, связи, с указанием их кардинальности и атрибутов.
Сущность изображается на диаграмме в виде прямоугольника, в который вписано ее имя. Одинарный контур прямоугольника указывает на сильный тип сущности, а двойной – на слабый. Атрибуты изображаются в виде эллипсов с их именем внутри и присоединяются к сущностям при помощи сплошных линий. Двойной контур эллипса указывает на многозначный атрибут, а пунктирный – на производный. Первичный ключ помечается подчеркиванием его имени. Если в ER-диаграмме присутствует составной атрибут, то его атрибуты-компоненты изображаются в виде эллипсов и присоединяются к нему (рис. 1). Зачастую используют упрощенный вид ER-диаграмм: на диаграмме изображаются только сущности, первичные ключи и связи (рис. 2).
Рис. 1. Сущность «Сотрудник»
На основании данных о внешних ключах, содержащейся в концептуальной модели, сущности связываются между собой, что отображается на ER-диаграмме. Связи изображаются в виде ромбов, внутри которых указывается смысл связи (рис. 2). Двойной контур ромба означает, что связь соединяет слабую сущность с сильной, от которой эта слабая сущность зависит [5].
Символы связей соединяются с символами сущностей сплошными линиями, причем двойная линия указывает на полную степень участия, а одинарная – на частичное. Кардинальность связи указывается со стороны символов сущностей около соединительных линий (рис. 3), которые также могут содержать ролевые имена для пояснения назначения сущностей.
Рис. 2. Упрощенный вид ER-диаграммы
Рис. 3. Кардинальность связей
При построении ER-диаграммы обучаемый может использовать инструментальные средства проектирования и моделирования баз данных. Например, Embarcadero ER/Studio, CA ERwin Data Modeler, Microsoft Visio, Oracle SQL Developer Data Modeler и другие.
После построения ER-диаграммы ее необходимо преобразовать с целью получения модели, пригодной для физического моделирования. На этом этапе необходимо устранить: связи типа «многие-ко-многим», сложные связи со степенью больше 2, рекурсивные связи, связи с атрибутами, множественные атрибуты, избыточные связи, а также перепроверить связи «один-к-одному» [5].
Проведение, указанных выше действий, приводит к переходу к реляционной модели базы данных. Она используется для нормализации отношений и, как следствие, устранению аномалий добавления/удаления/обновления данных. Для проведения процедуры нормализации необходимо определить функциональные зависимости для каждого отношения.