Введение. 3

1. Предметная область. 4

1.1 Описание ER-модели. 4

1.2 Реляционная модель. 4

2. Основные понятия баз данных. 4

2.1 Базы данных и системы управления базами данных. 4

2.2 Состав СУБД. 4

2.3 Структура простейшей базы данных. 4

2.4 Свойства полей базы данных. 4

2.5 Типы данных. 4

2.6 Безопасность баз данных. 4

3. Проектирование баз данных. 4

3.1  Режимы работы с базами данных. 4

3.2     Объекты базы данных. 4

3.2.1 Таблицы. 4

3.2.2 Запросы. 4

3.2.3 Формы. 4

3.2.4 Отчеты. 4

3.2.5 Страницы. 4

3.2.6 Макросы и модули. 4

3.3     Проектирование базы данных. 4

3.3.1 Разработка технического задания. 4

3.3.2 Разработка структуры базы данных. 4

4.  Реализация СУБД АЭРОпорт. 4

Приложение №1. 4

Приложение №2. 4

Приложение №3. 4

Приложение №4. 4

Приложение №5. 4

Приложение №6. 4

Список использованной литературы.. 4

Введение

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

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

Целью этой работы является создать базу данных в СУБД ACCESS. Которая должна будет автоматизировать работу служащих аэропорта.

1. Предметная область

1.1 Описание ER-модели

Аэропорт

                                     

                                                  1                              1


                                                                                                          ∞

Пассажиры

                                                                                                         

                                                                                                          1



                                   ∞

Самолет

                                                                                                          1

Бронь

                                   1

Билет

Рейс

                                   ∞

                                         1                                 ∞  
Свойство таблиц

1.     Аэропорт.

Так как мы будем разрабатывать базу данных, которую будут использоваться только на одном предприятии, то указывать свойства (другими словами, реквизиты нескольких аэропортов), на наш взгляд, не имеет смысла.

2.     Самолет

На наш взгляд для этой таблицы необходимы основные характеристики лайнеров, такие как:  Бортовой номер, Модель, Авиакомпания хозяин, Дата выпуска, Ресурс.

3.     Рейс

Для этой таблице будет необходимо: Во-первых, № рейса, который мы будем использовать как ключевое поле, во-вторых, время вылета, место вылети и место посадки, в-третьих, будем вводить бортовой номер самолета ( для связи этой таблицы с таблицей самолет), а также создадим 7 полей с названиями ПН,ВТ…ВС в которых будем указывать по каким дням недели будет выполняться этот рейс.

4.     Билет

В эту таблицу будут вводится данные вносимые в билет: № рейса, Дата вылета, Класс, Цена, Скидки, Налоги, Агентский сбор, Норма багажа, № билета, Бортовой номер.

5.     Пассажиры

В эту таблицу при покупке билета будут вноситься данные о пассажире: Фамилия, Имя, Отчество, Дата рождения, Страна, Место жительства, Паспортные данные.

6.     Бронь

В этой таблице будут данные, вносимые оператором при бронировании билета: Направление, Предоплата, Дата брони, Паспортные данные, ФИО, На какой день.

         Связь 1 к ∞ реализуется следующим образом: ключ из главной таблицы переносится в вспомогательную таблицу.

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

2.5 Типы данных.

Таблицы баз данных, как правило, допускают работу с гораздо большим количеством разных типов данных. Так, например, базы данных Microsoft Access работают со следующими типами данных.

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

Числовой – тип данных для хранения действительных чисел.

Поле Мемо – специальный тип данных для хранения больших объемов текста (до 65 535 символов). Физически текст не хранится в поле. Он храниться в другом месте базы данных, а в поле храниться указатель на него, но для пользователя такое разделение заметно не всегда.

Дата/время – тип данных для хранения календарных дат и текущего времени.

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

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

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

Гиперссылка – специальное поле для хранения адресов URL Web-объектов Интернета. При щелчке на ссылке автоматически происходит запуск броузера и воспроизведение объекта в его окне.

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

 

2.6 Безопасность баз данных.

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

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

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

3. Проектирование баз данных.

3.1  Режимы работы с базами данных.

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

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

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

3.2             Объекты базы данных.3.2.1      Таблицы.

Таблицы – это основные объекты любой базы данных. Во-первых, в таблицах хранятся все данные, имеющиеся в базе, а во-вторых, таблицы хранят и структуру базы (поля, их типы и свойства).

3.2.2      Запросы.

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

3.2.3      Формы.

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

3.2.4      Отчеты.

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

3.2.5      Страницы.

Это специальные объекты баз данных, реализованных в последних версиях СУБД  Microsoft Access (начиная с  Access 2000). Правда, более коректно их называть страницами доступа к данным. Физически это особый объект, выполненный в коде HTML, размещаемый на Web-странице и передаваемый клиенту вместе с ней. Сам по себе этот объект не является базой данной, но содержит компоненты, через которые осуществляется связь переданной Web-страницы с базой данных, остающейся на сервере. Пользуясь этими компонентами, посетитель Web-узла может просматривать записи базы в полях страницы доступа. Таким образом, страницы доступа к данным осуществляют интерфейс между клиентом, сервером и базой данных, размещенной на сервере. Эта база данных не обязательно должна быть базой данных Microsoft Access. Страницы доступа, созданные средствами Microsoft Access, посволяют работать также с базами данных Microsoft SQL Server.

3.2.6      Макросы и модули.

Эти категории объектов предназначены как для автоматизации повторяющихся операций при работе с СУБД, так и для создания новых функций путем программирования. В СУБД Microsoft Access макросы состоят из последовательности внутренних команд СУБД и являются одним из средств автоматизации работы с базой. Модули создаются средствами внешнего языка программирования, в данном случае языка Visual Basic for Applications. Это одно из средств, с помощью которых разработчик базы может заложить в нее нестандартные функциональные возможности, удовлетворить специфическое требование заказчика, повысить быстродействие системы управления, а также уровень ее защищенности.

3.3             Проектирование базы данных.

Методически правильно начинать работу с карандашом и листом бумаги в руках, не используя компьютер. На данном этапе он просто не нужен. Неоптимальные решения и прямые ошибки, заложенные на этапе проектирования, впоследствии очень трудно устраняются, поэтому этот этап является основополагающим.

3.3.1 Разработка технического задания.

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

Демонстрируют заказчику работу аналогичной базы данных, после чего согласовывают спецификацию отличий;

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

При подготовке технического задания составляют:

·        Список исходных данных, с которыми работает заказчик;

·        Список выходных данных, которые необходимы заказчику для управления структурой своего предприятия;

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

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

3.3.2 Разработка структуры базы данных.

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

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

2. В соответствии с типом данных, размещаемых в каждом поле, определяют наиболее подходящий тип для каждого поля.

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

4. В каждой из таблиц намечают ключевое поле. В качестве такого выбирают поле, данные в котором повторяться не могут. Например, для таблицы данных о студентах таким поле может служить индивидуальный шифр студента. Для таблицы, в которой содержаться расписание занятий, такого поля можно и не найти, но его можно создать искусственным комбинированием полей «Время занятия» и «Номер аудитории». Эта комбинация не повторима, так как в одной аудитории в одно и то же время не принято проводить два различных занятия. Если в таблице вообще нет ни каких полей, которые можно было бы использовать, как ключевые, всегда можно ввести дополнительное поле типа Счетчик – оно не может содержать повторяющихся данных по определению.

5. С помощью карандаша и бумаги расчерчивают связи между таблицами. Такой чертеж называется схемой данных. Существует несколько типов возможных связей между таблицами. Наиболее распространенными являются связи «один ко многим» и «один к одному». Связь между таблицами организуется на основе общего поля, причем в одной из таблиц оно обязательно должно быть ключевым, то есть на стороне «один» должно выступать ключевое поле, содержащее уникальные, неповторяющиеся значения. Значения на стороне «многие» могут повторяться.

6. Разработкой схемы данных заканчивается «бумажный» этап работы над техническим предложением. Эту схему можно согласовать с заказчиком, после чего приступать к непосредственному созданию базы данных.

Следует помнить, что по ходу разработки проекта заказчику непременно будут приходить в голову новые идеи. На всех этапах проектирования он стремится охватить единой системой все новые и новые подразделения и службы предприятия. Возможность гибкого использования его пожеланий во многом определяется квалификацией разработчика базы данных. Если схема данных составлена правильно, подключать к базе новые таблицы нетрудно. Если структура базы нерациональна, разработчик может испытать серьезные трудности и войти в противоречие с заказчиком. Противоречия исполнителя с заказчиком всегда свидетельствуют о недостаточной квалификации исполнителя. Именно по этому этап предварительного проектирования базы данных следует считать основным. От его успеха зависит, насколько база данных станет удобной, и будут ли с ней работать пользователи. Если отмечается, что пользователи базы «саботируют» ее эксплуатацию и предпочитают работать традиционными методами, это говорит не о низкой квалификации пользователей, а о недостаточной квалификации разработчика базы.

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

4.  Реализация СУБД АЭРОпорт

В ходе проделанной работы, нами были созданы:

ü    8 таблиц (Структура таблицы «Билет» указан в  Приложении №1).

ü    10 запросов, из них 9 на выборку и 1 на удаление (Структура запроса «№ билета запрос» указан в Приложении №2)

ü    19 таблиц (Пример формы «Пассажиры» указан в Приложении №3)

ü    1 отчет, который используется для печати билета (Пример отчета «Пассажиры Запрос1» указан в Приложении №4)

ü    28 макросов (Структура макроса «открытие запроса рейс» указана в Приложении №5)

ü    Написано несколько процедур на языке VBA, рассмотрим одну из них:

Как известно, система защиты СУБД ACCESS не очень надежна, к примеру, для того чтобы отключить макрос при запуске приложения, достаточно просто удерживать нажатой клавишу «Shift», как раз эту и еще некоторые другие горячие клавиши отключает эта процедура, так же она не позволяет добавлять новые Панели инструментов, а включает только одну (Пример указан в Приложении №6).

Рассмотрим код:

Private Sub butProtOff_Click()

setProtShift True MsgBox "Защита удалена!" & Chr(13) & Перезапустите базу данных!"

End Sub

Private Sub butProtOn_Click()

setProtShift False MsgBox "Защита установлена!" & Chr(13) & "Перезапустите базу данных!"

End Sub

Private Sub setProtShift(myFlag As Boolean)    dbChangeProperty "StartupForm",DB_TEXT, "пароль" – Первая форма(см. Приложение №6)

dbChangeProperty "StartupShowStatusBar", DB_BOOLEAN, myFlag – Нижняя полоска экрана

dbChangeProperty "AllowBuiltinToolbars", DB_BOOLEAN, myFlag – Панели инструментов

dbChangeProperty "AllowFullMenus", DB_BOOLEAN, myFlag –Меню таблиц, форм и т.п.

dbChangeProperty "AllowBreakIntoCode", DB_BOOLEAN, myFlag – Ошибки в модуле

dbChangeProperty "AllowSpecialKeys", DB_BOOLEAN, myFlag – Специальные ключи (CTRL+BREAK, ...)

dbChangeProperty "AllowBypassKey", DB_BOOLEAN, myFlag – Ключ Shift

End Sub

Function dbChangeProperty(strName As String, varType As Variant, varValue As Variant) As Boolean

Dim prp As Variant, dbs As Database

On Error GoTo 999 – Назначаем переход по ошибке

dbChangeProperty = False – Возвращаем результат при ошибке

Set dbs = CurrentDb – Выбираем базу

dbs.Properties(strName) = varValue – Присваиваем значение

dbChangeProperty = True – Возвращаем результат

Exit Function – Выходим из программы

999:If Err = 3270 Then  – Свойство не найдено

Set prp = dbs.CreateProperty(strName, varType, varValue) – Создаем свойство

 dbs.Properties.Append prp – Добавляем свойство

Err.Clear – Очищаем поток от ошибки

Resume Next – Возвращаемся к следующему оператору

End If

Err.Clear – Очищаем от незнакомой ошибки

End Function

Приложение №1

Структура формы «Билет»

Приложение №2

Структура запроса «№ билета запрос»

Приложение №3

Внешний вид формы «Пассажиры»

Приложение №4

Внешний вид отчета «Пассажиры Запрос1»

Приложение №5

Структура макроса «открытие запроса рейс»

Приложение №6

Список использованной литературы

1.Информатика. Базовый курс /Симонович С.В. и др. - СПб:   Издательство «Питер», 2000. – 640с.

2.  Информатика. Учебное пособие  /Под ред. В.Г. Кирия. – Иркутск:      ИрГТУ ,1998 часть 2. – 382с.

3. Информатика. Учебное пособие  /Ломтадзе В.В., Шишкина Л.П. – Иркутск: ИрГТУ, 1999. – 116с.