Построение реляционной базы данных
ВВЕДЕНИЕ
В современном информационном обществе, которое развивается и где все усложняется, человек становится абсолютно безпомощным и неспособным проследить за всеми событиями, новостями и новинками. Современная индустрия информации каждый день передаёт миллионы собщений, где многие из них могут иметь очень большое значение. Человеку доступно множество книг, журналов, газет, песен, фильмов или ресурсов Internet. Именно поэтому сегодня, как никогда раньше, нашу жизнь определяют механизмы распределения данных и знаний. Темпы развития зависят от информационных коммуникаций и их соответствия задачам, которые решаются. Совместное использование данных даёт безупречные преимущества коллективной работы. Единое информационное пространство позволяет аккумулировать информацию, которая относится ко всем аспектам бизнес процессу, быстро её обрабатывать, получать, обмениваться ею. Теория баз данных стала определяющим фактором при создании эффективных систем обработки информации.
Под базой данных понимается некоторая унифицированная совокупность данных, совместно используемая персоналом/населением группы, предприятия, региона, страны, мира...
Задача базы данных состоит в хранении всех представляющих интерес данных в одном или нескольких местах, причем таким способом, который заведомо исключает ненужную избыточность. Создание баз данных преследует две основные цели: понизить избыточность данных и повысить их надежность.
|
|
|
Целью курсового проекта является разработка базы данных школы. При проектировании БД был использовал реляционный подход, потому что реляционные базы получили наибольшее распространение в мире и они считаются наиболее перспективными в научном плане, т.к. большинство СУБД работают именно с такими базами.
АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
Выделение основных сущностей предметной области «Аэропорт»
В наше время воздушный транспорт (в частности самолёты) является наиболее быстрым и особенно ценится при перешении на далекие расстояния. В мире существует множество аэропортов и соответственно ещё больше маршрутов полетов. Эту информациию можно хранить в базе данных. Это обеспечит быстрый поиск, надежность хранения а главное доступность каждому пользователю ПК.
Проанализируем объекты реального мира. Для формирования концептуальной модели необходимо провести идентификацию объектов сущности базы данных.
В нашем случае мы имеем такие сущности как Самолеты, Полеты и Клиенты (заказчики билетов).
Далее проведем идентификацию характеристик этих сущностей.
Сущность Самолёты включает в себя следующие характеристики:
|
|
|
- Название самолета;
- Класс мест;
- Количество мест на каждый клас;
Сущность Полеты включает в себя следующие характеристики:
- Самолет;
- Аэропорт отправления;
- Город аэропорта отправления;
- Страна аэропорта отправления;
- Аэропорт прибытия;
- Город аэропорта прибытия;
- Страна аэропорта прибытия;
- Время отправления;
- Время прибытия;
Сущность Клиенты включает в себя следующие характеристики:
- Вся информация из сущьности Полеты;
- Дата отправления;
- Класс мест;
- Количество заказанных мест;
- Оплата (оплачен ли проезд (это нужно например для того чтобы узнать билеты куплены или заказаны)).
Заключительным шагом является установление соответствия между сущностями и характеристиками предметной области и отношениями и атрибутами в нотации выбранной СУБД.
Создание концептуальной модели базы данных
В ходе анализа предметной области, были определены ключевые абстракции, необходимые для организации базы данных: Сотрудники, Ученики.
Для решения поставленной задачи необходимо использовать структуру представленную на рисунке 1.1.
Рисунок 1.1 – Структура ключевых абстракций
Таким образом, мы получили простую модель, четко отражающую ключевые абстракции и предопределяющую дальнейший ход построения базы данных, в частности механизм взаимодействия с пользователем.
|
|
|
Таблица 1.1 – Ключевая абстракция «Самолеты»
| Характеристика | Тип |
| Название самолета | Строковый |
| Класс мест | Числовой целый |
| Количество мест на каждый клас | Числовой целый |
Таблица 1.2 – Ключевая абстракция «Полеты»
| Характеристика | Тип |
| Самолет | Строковый |
| Аэропорт отправления | Строковый |
| Город аэропорта отправления | Строковый |
| Страна аэропорта отправления | Строковый |
| Аэропорт прибытия | Строковый |
| Город аэропорта прибытия | Строковый |
| Страна аэропорта прибытия | Строковый |
| Время отправления | Время |
| Время прибытия | Время |
Таблица 1.3 – Ключевая абстракция «Заказы»
| Характеристика | Тип |
| Самолет | Строковый |
| Аэропорт отправления | Строковый |
| Город аэропорта отправления | Строковый |
| Страна аэропорта отправления | Строковый |
| Аэропорт прибытия | Строковый |
| Город аэропорта прибытия | Строковый |
| Страна аэропорта прибытия | Строковый |
| Время отправления | Время |
| Время прибытия | Время |
| Дата отправления | Дата |
| Класс мест | Числовой целый |
| Количетво билетов(мест) | Числовой целый |
| Оплата | Булево значение |
ПОСТАНОВКА ЗАДАЧИ
|
|
|
Разработать в среде программирования Delphi программу, реализующую базу данных школы. Организовать работу с приложением удобным для пользователя образом:
- менюориентированный интерфейс;
- подсказки ко всем возможным действиям пользователя;
- предупреждение некорректных ситуаций и др.
БД должна позволять производить просмотр и модификацию информации.
Во время создания базы данных следует принимать во внимание следующие требования:
- база данных должна удовлетворять всем требованиям пользователей к ее содержимому. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
- база данных обязана гарантировать непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
- база данных должна обеспечивать естественное, легкое для восприятия структурирование информации.
- база данных должна удовлетворять требованиям пользователей к ее производительности.
Перечислим функции, которые должна выполнять разрабатываемая программа:
- просмотр всей информации, которая находится в базе;
- дополнение, удаление, редактирование записей базы данных.
Для удобного поиска интересующей информации необходимо реализовать:
- сортировку записей;
- фильтрацию записей согласно с введенными значениями отдельных полей или их диапазонов;
- выборку и компоновку данных, которые находятся в разных таблицах с помощью статических и динамических запросов SQL;
- анализ информации, которая находится в базе данных.
ПОСТРОЕНИЕ БАЗЫ ДАННЫХ
Построение реляционной базы данных
При проектировании базы данных решаются две основных проблемы:
- Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.)? Часто эту проблему называют проблемой логического проектирования баз данных.
- Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных.
В случае реляционных баз данных трудно представить какие-либо общие рецепты по части физического проектирования. Здесь слишком много зависит от используемой СУБД. Например, при работе с СУБД Ingres можно выбирать один из предлагаемых способов физической организации отношений, при работе с System R следовало бы, прежде всего, подумать о кластеризации отношений и требуемом наборе индексов и т.д. Поэтому мы ограничимся вопросами логического проектирования реляционных баз данных, которые существенны при использовании любой реляционной СУБД.
В соответствии с принятой концептуальной моделью составляем таблицу, т.е. проектируем реляционную модель БД. Таблица 3.1
Таблица 3.1 - Реляционная модель БД «Самолёты»
| Самолёты | |
| Номер | Модель |
Таблица 3.2 - Реляционная модель БД «Места»
| Места | |||
| Номер | Номер самолёта | Класс места | Количество мест |
Таблица 3.3 - Реляционная модель БД «Полёты»
| Полёты | |||||
| Номер | Номер самолёта | Врема взлета | Время посадки | Аэропорт отправления | Аэропорт прибытия |
Таблица 3.4 - Реляционная модель БД «Аэропорты»
| Аэропорты | |||
| Номер | Название | Город | Страна |
Таблица 3.5 – Реляционная модель БД «Заказы»
| Аэропорты | |||||
| Номер | Номер полёта | Дата полёта | Индиф номер мест | Количество мест | Оплата (оплачено/нет) |
Нормализация базы данных
Важность нормализации состоит в том, что она позволяет разбить большие отношения, как правило, содержащие большую избыточность информации, на более мелкие логические единицы, группирующие только данные, объединенные “по природе”. Таким образом, идея нормализации заключается в следующем. Каждая таблица в реляционной базе данных удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное значение, и никогда не может быть множества таких значений.
Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ).
Этот процесс включает:
- устранение повторяющихся групп (приведение к 1НФ);
- удаление частично зависимых атрибутов (приведение к 2НФ);
- удаление транзитивно зависимых атрибутов (приведение к 3НФ).
Приведение к первой нормальной форме. Когда поле в данной записи содержит более одного значения для каждого вхождения первичного ключа, такие группы данных называются повторяющимися группами. 1НФ не допускает наличия таких многозначных полей.
Приведение ко второй нормальной форме. Следующий важный шаг в процессе нормализации состоит в удалении всех неключевых атрибутов, которые зависят только от части первичного ключа. Такие атрибуты называются частично зависимыми. Неключевые атрибуты заключают в себе информацию о данной сущности предметной области, но не идентифицируют ее уникальным образом.
Приведение к третьей нормальной форме. Третий этап процесса приведения таблиц к нормальной форме состоит в удалении всех неключевых атрибутов, которые зависят от других неключевых атрибутов. Каждый неключевой атрибут должен быть логически связан с атрибутом (атрибутами), являющимся первичным ключом.
Теперь база данных нормализована. Структура нормализованной БД приведена в приложении А. Таким образом, получаем базу данных приведенную к 3НФ и содержащую упорядоченную информацию, детально отображающую рассматриваемую предметную область. Теперь, когда мы провели нормализацию таблиц с целью устранения избыточного дублирования данных и группирования информации в логически связанных единицах, сделаем ряд замечаний по вопросам проектирования баз данных. Необходимо четко понять, что разбиение информации на более мелкие единицы с одной стороны, способствует повышению надежности и непротиворечивости базы данных, а с другой стороны, снижает ее производительность, так как требуются дополнительные затраты процессорного времени (серверного или машины пользователя) на обратное “соединение” таблиц при представлении информации на экране . Иногда для достижения требуемой производительности нужно сделать отход от канонической нормализации, при этом ясно осознавая, что необходимо обеспечить меры по предотвращению противоречивости в данных. Поэтому всякое решение о необходимости того или иного действия по нормализации можно принимать, только тщательно проанализировав предметную область и класс поставленной задачи.
Дата добавления: 2018-10-26; просмотров: 197; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!