База данных аэропорта
Выделение основных сущностей предметной области "Аэропорт" и создание концептуальной модели базы данных. Построение реляционной базы данных и ее нормализация. Разработка прикладной программы: назначение и логическая структура, вызов и загрузка программы.
| Рубрика | Программирование, компьютеры и кибернетика |
| Вид | курсовая работа |
| Язык | русский |
| Дата добавления | 20.01.2009 |
| Размер файла | 202,6 K |
Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже
Студенты, аспиранты, молодые ученые, использующие базу знаний в своей учебе и работе, будут вам очень благодарны.
УДК xxxxxxxx
КПxxxxxxxxxx
№ госрегистрацииxxxxxx
Инв. №xxxxxxxx
МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ УКРАИНЫ
Харьковский национальный университет радиоэлектроники
Кафедра ПО ЭВМ
Комиссия:
проф. xxxxxxxx.
ст. пр. xxxxxxxxx.
ПОЯСНИТЕЛЬНАЯ ЗАПИСКА
к курсовой работе по дисциплине
“Организация баз данных и знаний”
на тему:
“База данных аэропорта”
Выполнил:
ст. гр. xxxxxxxxxx3
xxxxxxxxxx
Руководитель:
xxxxxxxx
Харьков 2001
РЕФЕРАТ
Пояснительная записка содержит: 24c., 7 рис., 2 приложения, 5 источников.
Тема курсовой работы - построение базы аэропорта.
Метод исследования - реляционная алгебра.
Объект исследования - предметная область «Аэропорт»
Целью данного курсового проекта было закрепление знаний, полученных при изучении дисциплины “Организация баз данных и знаний”, приобритение навыков для разработки баз данных, знакомство с программными продуктами.
При проектировании базы данных использовался реляционный подход. Проведен анализ предметной области в ходе которого были выявлены обьекты, взаимодействие которых носит существенный характер для функциональной деятельности предметной области, и их основные характеристики; построена концептуальная модель базы данных. Во время построения схемы базы данных были установлены отношения между обьектами и характеристиками предметной области с одной стороны, и между отношениями и атрибутами с другой стороны. Все отношения находятся в третьей нормальной форме, которая устраняет дублирования информации, что говорит о правильности разработанной БД. Была разработана физическая модель базы данных и программно реализована в системе управления базами данных Paradox 7.0. Результат исследования - база данных аэропорта и программа, управляющая этой базой данных. Результатом выполнения работы является приложение, которое позволяет просматривать и модифицировать информацию о самолетах, аэроптах, рейсах и создавать отчет по заказаным билетам.
Концептуальная модель, реляционная модель, база данных, третья нормальная форма, синхронизация содержимого наборов данных, поле, запись.
CОДЕРЖАНИЕ
- ВВЕДЕНИЕ
- 1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
- 1.1 Выделение основных сущностей предметной области «Аэропорт»
- 1.2 Создание концептуальной модели базы данных
- 2 ПОСТАНОВКА ЗАДАЧИ
- 3 ПОСТРОЕНИЕ БАЗЫ ДАННЫХ
- 3.1 Построение реляционной базы данных
- 3.2 Нормализация базы данных
- 4 РАЗРАБОТКА ПРИКЛАДНОЙ ПРОГРАММЫ
- 4.1 Общие сведения
- 4.2 Назначение и логическая структура
- 4.3 Вызов и загрузка
- 4.4 Руководство пользователя
- ВЫВОДЫ
- ПЕРЕЧЕНЬ ССЫЛОК
- Приложение А Таблицы, приведенные 3НФ
- Приложение Б Экранные формы
- ВВЕДЕНИЕ
- В современном информационном обществе, которое развивается и где все усложняется, человек становится абсолютно безпомощным и неспособным проследить за всеми событиями, новостями и новинками. Современная индустрия информации каждый день передаёт миллионы собщений, где многие из них могут иметь очень большое значение. Человеку доступно множество книг, журналов, газет, песен, фильмов или ресурсов Internet. Именно поэтому сегодня, как никогда раньше, нашу жизнь определяют механизмы распределения данных и знаний. Темпы развития зависят от информационных коммуникаций и их соответствия задачам, которые решаются. Совместное использование данных даёт безупречные преимущества коллективной работы. Единое информационное пространство позволяет аккумулировать информацию, которая относится ко всем аспектам бизнес процессу, быстро её обрабатывать, получать, обмениваться ею. Теория баз данных стала определяющим фактором при создании эффективных систем обработки информации.
Под базой данных понимается некоторая унифицированная совокупность данных, совместно используемая персоналом/населением группы, предприятия, региона, страны, мира...[1]
Задача базы данных состоит в хранении всех представляющих интерес данных в одном или нескольких местах, причем таким способом, который заведомо исключает ненужную избыточность. Создание баз данных преследует две основные цели: понизить избыточность данных и повысить их надежность.
Целью курсового проекта является разработка базы данных школы. При проектировании БД был использовал реляционный подход, потому что реляционные базы получили наибольшее распространение в мире и они считаются наиболее перспективными в научном плане, т.к. большинство СУБД работают именно с такими базами.
1 АНАЛИЗ ПРЕДМЕТНОЙ ОБЛАСТИ
1.1 Выделение основных сущностей предметной области «Аэропорт»
В наше время воздушный транспорт (в частности самолёты) является наиболее быстрым и особенно ценится при перещении на далекие расстояния. В мире существует множество аэропортов и соответственно ещё больше маршрутов полетов. Эту информациию можно хранить в базе данных. Это обеспечит быстрый поиск, надежность хранения а главное доступность каждому пользователю ПК.
Проанализируем объекты реального мира. Для формирования концептуальной модели необходимо провести идентификацию объектов сущности базы данных.
В нашем случае мы имеем такие сущности как Самолеты, Полеты и Клиенты (заказчики билетов).
Далее проведем идентификацию характеристик этих сущностей.
Сущность Самолёты включает в себя следующие характеристики:
Название самолета;
Класс мест;
Количество мест на каждый клас;
Сущность Полеты включает в себя следующие характеристики:
Самолет;
Аэропорт отправления;
Город аэропорта отправления;
Страна аэропорта отправления;
Аэропорт прибытия;
Город аэропорта прибытия;
Страна аэропорта прибытия;
Время отправления;
Время прибытия;
Сущность Клиенты включает в себя следующие характеристики:
Вся информация из сущьности Полеты;
Дата отправления;
Класс мест;
Количество заказанных мест;
Оплата (оплачен ли проезд (это нужно например для того чтобы узнать билетя куплены или заказаны)).
Заключительным шагом является установление соответствия между сущностями и характеристиками предметной области и отношениями и атрибутами в нотации выбранной СУБД.
1.2 Создание концептуальной модели базы данных
В ходе анализа предметной области, были определены ключевые абстракции, необходимые для организации базы данных: Сотрудники, Ученики.
Для решения поставленной задачи необходимо использовать структуру представленную на рисунке 1.1.
Рисунок 1.1 - Структура ключевых абстракций
Таким образом, мы получили простую модель, четко отражающую ключевые абстракции и предопределяющую дальнейший ход построения базы данных, в частности механизм взаимодействия с пользователем.
Таблица 1.1 - Ключевая абстракция «Самолеты»
|
Характеристика |
Тип |
|
|
Название самолета |
Строковый |
|
|
Класс мест |
Числовой целый |
|
|
Количество мест на каждый клас |
Числовой целый |
Таблица 1.2 - Ключевая абстракция «Полеты»
|
Характеристика |
Тип |
|
|
Самолет |
Строковый |
|
|
Аэропорт отправления |
Строковый |
|
|
Город аэропорта отправления |
Строковый |
|
|
Страна аэропорта отправления |
Строковый |
|
|
Аэропорт прибытия |
Строковый |
|
|
Город аэропорта прибытия |
Строковый |
|
|
Страна аэропорта прибытия |
Строковый |
|
|
Время отправления |
Время |
|
|
Время прибытия |
Время |
Таблица 1.3 - Ключевая абстракция «Заказы»
|
Характеристика |
Тип |
|
|
Самолет |
Строковый |
|
|
Аэропорт отправления |
Строковый |
|
|
Город аэропорта отправления |
Строковый |
|
|
Страна аэропорта отправления |
Строковый |
|
|
Аэропорт прибытия |
Строковый |
|
|
Город аэропорта прибытия |
Строковый |
|
|
Страна аэропорта прибытия |
Строковый |
|
|
Время отправления |
Время |
|
|
Время прибытия |
Время |
|
|
Дата отправления |
Дата |
|
|
Класс мест |
Числовой целый |
|
|
Количетво билетов(мест) |
Числовой целый |
|
|
Оплата |
Булево значение |
2 ПОСТАНОВКА ЗАДАЧИ
Разработать в среде программирования Delphi программу, реализующую базу данных школы. Организовать работу с приложением удобным для пользователя образом:
менюориентированный интерфейс;
подсказки ко всем возможным действиям пользователя;
предупреждение некорректных ситуаций и др.
БД должна позволять производить просмотр и модификацию информации.
Во время создания базы данных следует принимать во внимание следующие требования:
- база данных должна удовлетворять всем требованиям пользователей к ее содержимому. Перед проектированием базы необходимо провести обширные исследования требований пользователей к функционированию базы данных.
- база данных обязана гарантировать непротиворечивость и целостность данных. При проектировании таблиц нужно определить их атрибуты и некоторые правила, ограничивающие возможность ввода пользователем неверных значений. Для верификации данных перед непосредственной записью их в таблицу база данных должна осуществлять вызов правил модели данных и тем самым гарантировать сохранение целостности информации.
- база данных должна обеспечивать естественное, легкое для восприятия структурирование информации.
- база данных должна удовлетворять требованиям пользователей к ее производительности.
Перечислим функции, которые должна выполнять разрабатываемая программа:
- просмотр всей информации, которая находится в базе;
- дополнение, удаление, редактирование записей базы данных.
Для удобного поиска интересующей информации необходимо реализовать:
- сортировку записей;
- фильтрацию записей согласно с введенными значениями отдельных полей или их диапазонов;
- выборку и компоновку данных, которые находятся в разных таблицах с помощью статических и динамических запросов SQL;
- анализ информации, которая находится в базе данных.
3 ПОСТРОЕНИЕ БАЗЫ ДАННЫХ
3.1 Построение реляционной базы данных
При проектировании базы данных решаются две основных проблемы:
- Каким образом отобразить объекты предметной области в абстрактные объекты модели данных, чтобы это отображение не противоречило семантике предметной области и было по возможности лучшим (эффективным, удобным и т.д.)? Часто эту проблему называют проблемой логического проектирования баз данных. [2]
- Как обеспечить эффективность выполнения запросов к базе данных, т.е. каким образом, имея в виду особенности конкретной СУБД, расположить данные во внешней памяти, создание каких дополнительных структур (например, индексов) потребовать и т.д.? Эту проблему называют проблемой физического проектирования баз данных. [2]
В случае реляционных баз данных трудно представить какие-либо общие рецепты по части физического проектирования. Здесь слишком много зависит от используемой СУБД. Например, при работе с СУБД Ingres можно выбирать один из предлагаемых способов физической организации отношений, при работе с System R следовало бы, прежде всего, подумать о кластеризации отношений и требуемом наборе индексов и т.д. Поэтому мы ограничимся вопросами логического проектирования реляционных баз данных, которые существенны при использовании любой реляционной СУБД.
В соответствии с принятой концептуальной моделью составляем таблицу, т.е. проектируем реляционную модель БД. Таблица 3.1
Таблица 3.1 - Реляционная модель БД «Самолёты»
|
Самолёты |
||
|
Номер |
Модель |
Таблица 3.2 - Реляционная модель БД «Места»
|
Места |
||||
|
Номер |
Номер самолёта |
Класс места |
Количество мест |
Таблица 3.3 - Реляционная модель БД «Полёты»
|
Полёты |
||||||
|
Номер |
Номер самолёта |
Врема взлета |
Время посадки |
Аэропорт отправления |
Аэропорт прибытия |
Таблица 3.4 - Реляционная модель БД «Аэропорты»
|
Аэропорты |
||||
|
Номер |
Название |
Город |
Страна |
Таблица 3.5 - Реляционная модель БД «Заказы»
|
Аэропорты |
||||||
|
Номер |
Номер полёта |
Дата полёта |
Индиф номер мест |
Количество мест |
Оплата (оплачено/нет) |
3.2 Нормализация базы данных
Важность нормализации состоит в том, что она позволяет разбить большие отношения, как правило, содержащие большую избыточность информации, на более мелкие логические единицы, группирующие только данные, объединенные “по природе”. Таким образом, идея нормализации заключается в следующем. Каждая таблица в реляционной базе данных удовлетворяет условию, в соответствии с которым в позиции на пересечении каждой строки и столбца таблицы всегда находится единственное значение, и никогда не может быть множества таких значений.
Процесс нормализации заключается в приведении таблиц в так называемые нормальные формы. Существует несколько видов нормальных форм: первая нормальная форма (1НФ), вторая нормальная форма (2НФ), третья нормальная форма (3НФ).
Этот процесс включает:
- устранение повторяющихся групп (приведение к 1НФ);
- удаление частично зависимых атрибутов (приведение к 2НФ);
- удаление транзитивно зависимых атрибутов (приведение к 3НФ).
Приведение к первой нормальной форме. Когда поле в данной записи содержит более одного значения для каждого вхождения первичного ключа, такие группы данных называются повторяющимися группами. 1НФ не допускает наличия таких многозначных полей.
Приведение ко второй нормальной форме. Следующий важный шаг в процессе нормализации состоит в удалении всех неключевых атрибутов, которые зависят только от части первичного ключа. Такие атрибуты называются частично зависимыми. Неключевые атрибуты заключают в себе информацию о данной сущности предметной области, но не идентифицируют ее уникальным образом.
Приведение к третьей нормальной форме. Третий этап процесса приведения таблиц к нормальной форме состоит в удалении всех неключевых атрибутов, которые зависят от других неключевых атрибутов. Каждый неключевой атрибут должен быть логически связан с атрибутом (атрибутами), являющимся первичным ключом.
Теперь база данных нормализована. Структура нормализованной БД приведена в приложении А. Таким образом, получаем базу данных приведенную к 3НФ и содержащую упорядоченную информацию, детально отображающую рассматриваемую предметную область. Теперь, когда мы провели нормализацию таблиц с целью устранения избыточного дублирования данных и группирования информации в логически связанных единицах, сделаем ряд замечаний по вопросам проектирования баз данных. Необходимо четко понять, что разбиение информации на более мелкие единицы с одной стороны, способствует повышению надежности и непротиворечивости базы данных, а с другой стороны, снижает ее производительность, так как требуются дополнительные затраты процессорного времени (серверного или машины пользователя) на обратное “соединение” таблиц при представлении информации на экране [2]. Иногда для достижения требуемой производительности нужно сделать отход от канонической нормализации, при этом ясно осознавая, что необходимо обеспечить меры по предотвращению противоречивости в данных. Поэтому всякое решение о необходимости того или иного действия по нормализации можно принимать, только тщательно проанализировав предметную область и класс поставленной задачи.
4 РАЗРАБОТКА ПРИКЛАДНОЙ ПРОГРАММЫ
4.1 Общие сведения
Программа разработана в интегрированной среде программирования Delphi 5.0 и реализует работу с базой данных школы.
При разработке базы использовались следующие программные продукты: Borland Delphi 6.0; DataBase Desktop 7.0; BDE administrator 5.01.
Создаем в DataBase Desktop (DBD) 5 таблиц: таблицу самолётов, таблицу мест в самолете, таблицу полетов, таблицу аэропортов, таблицу заказов. Создаем таблицы с такими атрибутами:
Таблица 4.1 - Самолёты (Planes.db)
|
ПОЛЕ |
ТИП |
Назначение |
|
|
ID |
SHORT |
Идентификатор |
|
|
PlaneName |
ALPHA(30) |
Модель самолёта |
Таблица 4.2 - Места в самолёте (Seats.db)
|
ПОЛЕ |
ТИП |
Назначение |
|
|
ID |
LONGINTEGER |
Идентификатор |
|
|
ID_Plane |
SHORT |
Номер самолёта |
|
|
SeatCount |
SHORT |
Класс мест |
|
|
SeatType |
SHORT |
Количество мест |
Таблица 4.3 - Аэропорты (AirPorts.db)
|
ПОЛЕ |
ТИП |
Назначение |
|
|
ID |
SHORT |
Идентификатор |
|
|
AirPortName |
ALPHA(30) |
Название аэропорта |
|
|
City |
ALPHA(30) |
Город |
|
|
Country |
ALPHA(30) |
Страна |
Таблица 4.4 - Полёты (Flights.db)
|
ПОЛЕ |
ТИП |
Назначение |
|
|
ID |
INTEGER |
Идентификатор |
|
|
ID_Plane |
SHORT |
Номер самолёта |
|
|
UpTime |
TIME |
Врема взлета |
|
|
DownTime |
TIME |
Время посадки |
|
|
ID_AP_Up |
SHORT |
Аэропорт отправления |
|
|
ID_AP_Down |
SHORT |
Аэропорт прибытия |
Таблица 4.5 - Заказы (Orders.db)
|
ПОЛЕ |
ТИП |
Назначение |
|
|
ID |
LONG INTEGER |
Идентификатор |
|
|
ID_Flight |
SHORT |
Номер полёта |
|
|
FlightDate |
DATE |
Дата полёта |
|
|
ID_Seats |
LONG INTEGER |
Индиф номер мест |
|
|
SeatCount |
SHORT |
Количество мест |
|
|
Payed |
Boolean |
Оплата (оплачено/нет) |
4.2 Назначение и логическая структура
Создадим новый проект и добавим к нему модуль данных (TDataModule), на котором разместим 5 компонент TTable (tbAirPorts - аэропорты, tbPlanes - самолёты, tbSeats - места, tbFlights - полёты, tbOrders - заказы) и 5 компонент TDataSource, чтобы визуальные компоненты могли получить данные из таблиц, связанные с компонентами tblxxxxx. Также создаем 3 компонента TQuery? 2из которых будут выполнять статические запросы и один - динамические. 2 компоненты TTable будут связаны друг с другом по ключевым полям. Для этого устанавливаем свойства компонент MasterSource и MasterField, таким образом при переходе на любую запись, в подчиненной таблице будут видны все нужные записи.
На главной форме разместим все визуальные компоненты, для отображения содержимого таблиц (Edit) и програмным путем будем изменять в них занчения. Также для выбора значений из БД разместим несколько компонент TDBGrid. В некоторых таблицах будут добавлены самовычисляемые поля для улучшения восприятия данных.
Главная форма представляет собой две закладки на первой будет находится таблица для просмотра рейсов, на второй просмотр информации о рейсе а также заказ билетов.
В ходе тестирования программы было замечено что свойство .Post вносит изменения в таблицу но не сохраняет его на носителе информации, поэтому поскольку количество свободных мест подчитывается с помощью динамических запросов (компонент qWork1) после изменений значений в таблице заказов будем сохранять их на носителе с помощью вызова метода .Flush Buffers.
Создадим формы для добавления новых самолетов, рейсов и аэропортов (рис. Б.3, Б.4, Б.5).
Перед удалением записи пользователю выдается предупреждение об ошибке. И если он подтверждает своё желание удалить запись, то по идентификатору удаляются все записи из таблиц с помощью компонента Query.
4.3 Вызов и загрузка
Для просмотра проекта программы необходимо Delphi 6.0 и BDE, создание псевдонима не требуется, но таблицы должны находится в <папка с исполняемым файлом>\Data.
Для запуска программы необходимо запустить на выполнение файл AirPortAdministrator.exe.
4.4 Руководство пользователя
Программа предназначена для облегчения и повышения производительности труда кассиров.
Для реализации идеи программы была выбрана СУБД BDE, что позволило использовать удобный и мощный формат таблиц Paradox. Таким образом, появилась возможность создать высокопроизводительное приложение. В качестве средства разработки была выбрана среда разработки Delphi версии 6.0 фирмы Borland. Это позволило сократить время на разработку программы за счет использования стандартных компонентов VCL, а также создать высокопроизводительное легко переносимое приложение для баз данных.
После запуска программы появляется главное окно программы (рис. Б.1). Оно состоит из Панели инструментов и выпадающего меню. В выпадающем меню все пункты меню аналогичны кнопкам.
Чтобы добавить запись в существующую таблицу, необходимо щелкнуть по соответствующей кнопке «Новый самолет», «Добавить рейс» или «Новый аэропорт», находящейся на панели инструментов главного окна или меню. После этого откроется окно добавления записи (рис. Б.3, Б.4, Б.5)
Поля идентификатов будут заполнены автоматически. Некоторые поля будут заполняться с помощью автоматически генерируищихся списков, для того чтобы заполнить эти поля, откройте окно со списком и выберите нужную запись. Это уменьшит до минимума шанс на возникновение ощибки.
В поле «Дата полёта» вносится дата по шаблону : дд.мм.гг. с помощью компонента TDataTimePicker
Если вся необходимая информация внесена верно, то щелкните левой клавишей мыши по кнопке «Добавить запись», если неверно, то исправьте введенные данные в тех полях, где это необходимо и щелкните по кнопке - это позволит сохранить внесенные данные в базе данных.
Если поля были не заполнены, то появится предупреждение о том, что необходимо заполнить все поля.
Если такая запись уже существует в базе данных, то появится предупреждение о дублировании информации.
Для того чтобы удалить заказ, нажмите на кнопку «Отменить заказ» на панели инструментов главного окна или меню. Появится предупреждение, и если вы действительно хотите удалить эту запись, то нажмите кнопку “Yes”.
Если вы захотите выйти из этой программы, то необходимо нажать на кнопку “Выход”.
ВЫВОДЫ
В данной работе разработана база данных, реализующая базу данных аэропорта.
В процессе выполнения курсовой работы были закреплены знания, полученые при изучении дисциплины «Организация баз данных и знаний». Были изучено такие пункты:
анализ предметной области;
построение концептуальной модели предметной области;
построение логической модели базы данных;
организация базы данных;
разработка прикладной программы;
наполнение и сопровождение базы данных;
подготовка программной документации.
В процессе организации БД проведен до необходимого уровня абстракций анализ предметной области, построены концептуальная и реляционная модель БД, произведена нормализация реляционной БД. Оформляя пояснительную записку, были ознакомлены с государственными стандартами ДСТУ 3008-95. При разработке механизма функционирования приложения использованы такие средства Delphi 6.0 работы с базами данных как синхронизация содержимого наборов данных, поиск по части составного ключа и др. Была освоена и закреплена работы с такими прикладными программами:
Borland Delphi 6.0;
DataBase Desktop 7.0;
BDE administrator 5.01;
Microsoft Word;
Были закреплены знания в области программирования, в частности были использованы такие языки программирования, как Object Pascal и SQL.
ПЕРЕЧЕНЬ ССЫЛОК
1. Атре Ш. Структурный подход к организации баз данных. - М.: Финансы и статистика, 1983. - 320 с.
2. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. - М.: Финансы и статистика, 1989. - 351 с.
3. Дейт К. Руководство по реляционной СУБД DB2. - М.: Финансы и статистика, 1988. - 320 с.
4. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. - 252 с.
5. Кириллов В.В. Структурированный язык запросов (SQL). - СПб.: ИТМО, 1994. - 80 с.
Приложение А
Рисунок А.2 - Таблицы БД, приведенные к 3НФ
Приложение Б
Рисунок Б.1 - Главная форма программы
Рисунок Б.2 - Форма добавления нового аэропорта
Рисунок Б.3 - Форма добавления нового самолёта
Рисунок Б.4 - Форма добавления нового рейса
Подобные документы
Создание концептуальной модели СУБД Аэропорт, призванной автоматизировать работу служащих аэропорта. Схема данных, создание запросов, их формы. Построение базы данных и ее нормализация. Разработка прикладной программы: логическая структура, режимы работы.
курсовая работа [1,9 M], добавлен 06.12.2010Выбор средств разработки базы данных для информационного функционирования аэропорта. Выделение и нормализация сущностей. Логическая схема и физическая структура базы данных. Спецификация и тестирование функций, процедур, триггеров, представлений.
курсовая работа [1,5 M], добавлен 07.06.2013Построение концептуальной модели, процесс моделирования смыслового наполнения базы данных. Основные компоненты концептуальной модели. Построение реляционной модели. Целостность данных в реляционной базе. Нормализация. Проектирование базы данных в ACCESS.
курсовая работа [1,8 M], добавлен 29.10.2008Разработка базы данных для компании, занимающейся авиагрузоперевозками, снабженной средствами идентификации пользователей. Описание ее предметной области и функций. Разработка интерфейса программы. Построение концептуальной и реляционной модели БД.
курсовая работа [2,1 M], добавлен 15.06.2014Создание базы данных в СУБД ACCESS для автоматизации работы служащих аэропорта, этапы проектирования реляционной БД. Построение инфологической модели ПО. Разработка средств обеспечения безопасности данных; функциональное назначение программного средства.
курсовая работа [3,8 M], добавлен 25.06.2011Анализ предметной области. Проектирование концептуальной модели. Разработка логической структуры базы данных. Выделение информационных объектов. Создание глобальной схемы связей. Поддержка целостности данных. Структура и назначение существующих форм.
курсовая работа [1,4 M], добавлен 23.09.2016Сущность базы данных. Процесс построения концептуальной модели. Построение реляционной модели, создание ключевого поля. Процесс нормализации. Проектирование базы данных в ACCESS. Порядок создание базы данных. Создание SQL запросов и работа в базе данных.
курсовая работа [185,6 K], добавлен 08.11.2008Построение инфологической концептуальной модели предметной области. Структура базы данных Microsoft Office Access. Формы, запросы и отчеты. Создание форм, запросов и отчетов в базах данных. Схема данных физической и логической сущности в Erwin 4.0.
курсовая работа [5,1 M], добавлен 13.12.2011Описание предметной области, определение функциональных требований к системе и построение диаграммы потока данных. Построение модели "сущность-связь", описание сущностей и атрибутов модели. Построение реляционной базы данных и описание ее таблицы.
курсовая работа [624,5 K], добавлен 30.05.2019Информационный анализ и выявление основных сущностей предметной области и их основных свойств. Построение концептуальной модели (модель сущность-связь). Определение логической модели реляционной базы данных. Решение задач средствами проектирования СУБД.
курсовая работа [3,0 M], добавлен 25.11.2013
