Вторая нормальная форма - создаются отдельные таблицы для наборов значений, относящихся к нескольким записям, эти таблицы связуются с помощью внешнего ключа.
ПОСТАНОВКА ЗАДАЧИ
При выполнении курсового проектирования будет создана база данных для службы грузоперевозок, составлена необходимая документация.
Целью курсового проекта является ознакомление с данной предметной областью, составление диаграмм потоков данных, «сущность-связь», контекстной диаграммы, составление иерархической, реляционной, сетевой модели данных, разработка базы данных для службы грузоперевозок, которая будет выполнять возложенные на неё функции, создание интерфейса для работы с базой.
Задачей курсового проектирования является создание базы данных, которая должна обеспечить удобство пользователю, который будет работать с большим количеством информации. Она должна обеспечивать удобное добавление, удаление данных, поиск среди заданных данных.
База данных должна поддерживать архивацию, восстановление и резервное копирование данных, обеспечивать защиту данных с помощью организации различных уровней доступа. База данных должна составлять отчёты по запросу пользователя. Также БД должна содержать различного рода подсказки и справку.
3. КОНЦЕПТУАЛЬНОЕ ПРОЕКТИРОВАНИЕ СИСТЕМЫ
Концептуальное проектирование систем — начальная стадия проектирования, на которой принимаются определяющие последующий облик решения, и проводится исследование и согласование параметров созданных технических решений с возможной их организацией. При проектировании концептуальной системы мы получим непротиворечивую структурированную интерпретацию реально существующей системы и взаимосвязи её структурных компонентов.
3.1 Инфологическое моделирование предметной области
Инфологическое проектирование — построение семантической модели предметной области наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. В семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером (Hammer) и Мак-Леоном (McLean) в 1981 году, функциональную модель данных Шипмана (Shipman), также созданную в 1981 году, модель «сущность-связь», предложенную Ченом (Chen) в 1976 году, и ряд других моделей. У всех моделей были свои положительные и отрицательные стороны. В настоящий момент не существует единой общепринятой системы обозначений для ER-модели и разные CASE-системы используют разные графические нотации.
В данном курсовом проекте мы рассмотри диаграммы потоков данных и диаграмму «сущность-связь»
3.1.1 Построение диаграммы потоков данных
Диаграммы потоков данных представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами.
Функции, хранилища и внешние сущности на DFD-диаграмме связываются дугами, представляющими потоки данных. Дуги могут разветвляться или сливаться, что означает, соответственно, разделение потока данных на части, либо слияние объектов. При интерпретации DFD-диаграммы используются следующие правила:
· функции преобразуют входящие потоки данных в выходящие;
· хранилища данных не изменяют потоки данных, а служат только для хранения поступающих объектов;
· преобразования потоков данных во внешних сущностях игнорируется.
Построим DFD диаграмму для данной предметной области (см. рис. 3.1).
Рисунок 3.1- DFD-диаграмма
3.1.2 Построение диаграммы «сущность-связь»
Диаграммы "сущность-связь" (ERD) предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей).
Сущность представляет собой множество экземпляров реальных или абстрактных объектов (людей, событий, состояний, идей, предметов и т.п.), обладающих общими атрибутами или характеристиками. Любой объект системы может быть представлен только одной сущностью, которая должна быть уникально идентифицирована. При этом имя сущности должно отражать тип или класс объекта, а не его конкретный экземпляр.
Отношение в самом общем виде представляет собой связь между двумя и более сущностями. Именование отношения осуществляется с помощью грамматического оборота глагола.
Другими словами, сущности представляют собой базовые типы информации, хранимой в базе данных, а отношения показывают, как эти типы данных взаимоувязаны друг с другом. Введение подобных отношений преследует две основополагающие цели:
• обеспечение хранения информации в единственном месте (даже если она используется в различных комбинациях);
• использование этой информации различными приложениями.
Для идентификации требований, в соответствии с которыми сущности вовлекаются в отношения, используются СВЯЗИ. Каждая связь соединяет сущность и отношение и может быть направлена только от отношения к сущности.
Пара значений связей, принадлежащих одному и тому же отношению, определяет тип этого отношения. Практика показала, что для большинства приложений достаточно использовал следующие типы отношений:
1. 1*1 (один-к-одному). Отношения данного типа используются, как правило, на верхних уровнях иерархии модели данных, а на нижних уровнях встречаются сравнительно редко.
2. 1*n (один-к-многим). Отношения данного типа являются наиболее часто используемыми.
3. n*m (многие-к-многим). Отношения данного типа обычно используются на ранних этапах проектирования с целью прояснения ситуации. В дальнейшем каждое из таких отношений должно быть преобразовано в комбинацию отношений типов 1 и 2 (возможно, с добавлением вспомогательных сущностей и введением новых отношений).
На рисунке 3.2 приведена диаграмма «Сущность-связь» для службы грузоперевозок.
Рисунок 3.2 – Диаграмма «Сущность-связь»
Объекты клиент и договор связаны отношением 1: , так как 1 клиент заключает множество договоров, а 1 договор заключается одним клиентом.
Объекты договор, машина груз связаны отношением ::, так как 1 договор обслуживает 1 машина, которая перевозит много грузов, 1 машина обслуживает много договоров и перевозит множество грузов, 1 груз перевозит машина по одному договору.
Объекты категория груза, груз связаны отношением 1:, так как 1 груз имеет одну категорию груза, а 1 категорию груза имеют множество грузов.
3.2 Выбор модели представлении данных
3.2.1 Иерархическая модель данных
Иерархическая модель данных — представление базы данных в виде древовидной (иерархической) структуры, состоящей из объектов (данных) различных уровней.
В основе иерархической модели данных лежит один главный элемент (главный узел), с которого все и начинается, такой элемент называет корневым элементом, в теории графов это называется корнем дерева. Вообще, по сути, что сетевая база данных, что иерархическая база данных имеет древовидную структуру. Все элементы или узлы, которые находятся ниже корневого узла иерархической модели, являются потомками корня. Стоит сказать, что и иерархическая база данных, и сетевая база данных оптимизированы на чтение информации из БД, но не на запись информации в базу данных, эта особенность обусловлена самой моделью данных.
Узлы дерева, которые находятся на одном уровне, обычно называются братьями. Узлы, которые находятся ниже какого-то определенного уровня, являются дочерними узлами по отношению к нему.
К достоинствам иерархической модели данных относятся эффективное использование памяти ЭВМ и неплохие показатели времени выполнения операций над данными.
Недостатком иерархической модели является ее громоздкость для обработки информации с достаточно сложными логическими связями.
Иерархическая модель данных для рассматриваемой предметной области приведена на рисунках 3.3, 3.4, 3.5
Клиент
| ФИО | Адрес | Телефон | Реквизиты |
Договор
| Выполнение договора | № договора | Дата заключения | Адрес погрузки | Адрес разгрузки | Время погрузки | Время доставки | Срок доставки | Расстояние | Габариты груза | Масса груза | Стоимость |
Машина Груз
| Наименование груза |
| ФИО водителя | Марка | Грузоподъёмность | Тип погрузки | Максимальные габариты |
Рисунок 3.3 – Первый фрагмент иерархической модели данных
Категория груза
| Название категории груза |
Груз
| Наименование груза |
Машина
| ФИО водителя | Марка | Грузоподъёмность | Тип погрузки | Максимальные габариты |
Договор
| Выполнение договора | № договора | Дата заключения | Адрес погрузки | Адрес разгрузки | Время погрузки | Время доставки | Срок доставки | Расстояние | Габариты груза | Масса груза | Стоимость |
Рисунок 3.4 – Второй фрагмент иерархической модели данных
Машина
| ФИО водителя | Марка | Грузоподъёмность | Тип погрузки | Максимальные габариты |
Груз
| Наименование груза |
Договор
| Выполнение договора | № договора | Дата заключения | Адрес погрузки | Адрес разгрузки | Время погрузки | Время доставки | Срок доставки | Расстояние | Габариты груза | Масса груза | Стоимость |
Рисунок 3.5 – Третий фрагмент иерархической модели данных
3.2.2 Сетевая модель данных
Сетевая модель данных - это логическая модель данных, представляющая их сетевыми структурами типов записей и связанные отношениями мощности один-к-одному или один-ко-многим.
Сетевая модель данных определяется в тех же терминах, что и иерархическая. Она состоит из множества записей, которые могут быть владельцами или членами групповых отношений.
Основное различие этих моделей состоит в том, что в сетевой модели запись может быть членом более чем одного группового отношения. Согласно этой модели каждое групповое отношение именуется и проводится различие между его типом и экземпляром. Тип группового отношения задается его именем и определяет свойства общие для всех экземпляров данного типа. Экземпляр группового отношения представляется записью-владельцем и множеством (возможно пустым) подчиненных записей. При этом имеется следующее ограничение: экземпляр записи не может быть членом двух экземпляров групповых отношений одного типа.
Преимущества:
1. Стандартизация. Появление стандарта CODASYL, который определил базовые понятия модели и формальный язык описания.
2. Быстродействие. Быстродействие сетевых баз данных сравнимо с быстродействием иерархических баз данных.
3. Гибкость. Множественные отношения предок/потомок позволяют сетевой базе данных хранить данные, структура которых была сложнее простой иерархии.
4. Универсальность. Выразительные возможности сетевой модели данных являются наиболее обширными в сравнении с остальными моделями.
5. Возможность доступа к данным через значения нескольких отношений (например, через любые основные отношения).
Недостатки:
1. Жесткость. Наборы отношений и структуру записей необходимо задавать наперёд. Изменение структуры базы данных ведет за собой перестройку всей базы данных. Связи закреплены в записях в виде указателей. При появлении новых аспектов использования этих же данных может возникнуть необходимость установления новых связей между ними. Это требует введения в записи новых указателей, т.е. изменения структуры БД, и, соответственно, переформирования всей базы данных.
2. Сложность. Сложная структура памяти.
Сетевая модель данных для данной предметной области приведена на рисунке 3.6.
| ДОГОВОР | |||||||||||
| Выполнение договора | № договора | Дата заключения | Адрес погрузки | Адрес разгрузки | Время погрузки | Время доставки | Срок доставки | Расстояние | Габариты груза | Масса груза | Стоимость |
| КЛИЕНТ | |||
| ФИО | Адрес | Телефон | Реквизиты |
| МАШИНА | ||||
| ФИО водителя | Марка | Грузоподъёмность | Тип погрузки | Максимальные габариты |
| ГРУЗ |
| Наименование груза |
 КАТЕГОРИЯ ГРУЗА
|
 Название категории груза
|
Рисунок 3.6. - Сетевая модель данных
3.2.3 Реляционная модель данных
Реляционная модель данных предложена сотрудником фирмы IBM Эдгаром Коддом и основывается на понятии отношение.
Отношение представляет собой множество элементов, называемых кортежами. Наглядной формой представления отношения является привычная для человеческого восприятия двумерная таблица.
Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам – атрибуты отношения.
С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно деление одного объекта (явления, сущности, системы и проч.), информация о котором хранится в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. При этом каждый из подобъектов имеет одинаковую структуру или свойства, описываемые соответствующими значениями полей записей. Например, таблица может содержать сведения о группе обучаемых, о каждом из которых известны следующие характеристики: фамилия, имя и отчество, пол, возраст и образование. Поскольку в рамках одной таблицы не удается описать более сложные логические структуры данных из предметной области, применяют связывание таблиц.
Физическое размещение данных в реляционных базах на внешних носителях легко осуществляется с помощью обычных файлов.
Достоинство реляционной модели данных заключается в простоте, понятности и удобстве физической реализации на ЭВМ. Именно простота и понятность для пользователя явились основной причиной их широкого использования. Проблемы же эффективности обработки данных этого типа оказались технически вполне разрешимыми.
Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
На рисунке 3.7 изображена РМД в виде нескольких таблиц для данной предметной области.
| #КК | ФИО | Адрес | Телефон | Реквизиты |
 N
| C64 | C32 | N12 | N20 |
| #КД | Дата заключения | Адрес погрузки | Адрес разгрузки | Время погрузки | Время доставки | Срок доставки | Расстояние, км | Габариты груза | Масса груза | KK# | КВ# | Выполнение договора |
| N | D10 | C32 | C32 | T8 | T8 | D10 | N3 | C12 | N4 | N |  N
| L1 |
 |  | ||
| #КВ | #КМ | ФИО водителя | Грузоподъёмность | Максимальные габариты |
| N | N | C64 | N5 | C12 |
| #КМ | Марка | Тип погрузки |
| N | C12 | C16 |
Машина
 |
 КД#
| КГ# | Кол-во ходок | Количество грузов |
| N | N | N2 | N2 |
| #КГ | Наименование груза | ККГ# |
| N | C16 |  N
|
 |
| #ККГ | Название категории груза |
| N | C32 |
Рисунок 3.7 – Реляционная модель данных
В полученной РМД каждому объекту диаграммы «Сущность-связь» соответствует таблица. Ключевым полем каждой таблицы является поле, содержащее уникальный ключ, который помечается символом # для наглядности. Таблица «Обслуживание договора» возникла в результате преобразование связи многие ко многим. Таблица «Машина» является справочной таблицей, созданной с целью повышения эффективности работы СБД.
3.3 Нормализация таблиц БД
Нормализация — это процесс организации данных в базе данных, включающий создание таблиц и установление отношений между ними в соответствии с правилами, которые обеспечивают защиту данных и делают базу данных более гибкой, устраняя избыточность и несогласованные зависимости. Избыточность данных приводит к непродуктивному расходованию свободного места на диске и затрудняет обслуживание баз данных. Например, если данные, хранящиеся в нескольких местах, потребуется изменить, в них придется внести одни и те же изменения во всех этих местах.
Существует несколько правил нормализации баз данных. Каждое правило называется «нормальной формой». Если выполняется первое правило, говорят, что база данных представлена в «первой нормальной форме». Если выполняются три первых правила, считается, что база данных представлена в «третьей нормальной форме».
Первая нормальная форма - устраняются повторяющиеся группы в отдельных таблицах, создаётся отдельная таблица для каждого набора связанных данных, идентифицируется каждый набор связанных данных с помощью первичного ключа.
Вторая нормальная форма - создаются отдельные таблицы для наборов значений, относящихся к нескольким записям, эти таблицы связуются с помощью внешнего ключа.