2. Определение логической модели базы данных.

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

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

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

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

Если декомпозировать этот объект «таблица» на две: AirCompany и LA, то, с учетом того, что в каждой авиакомпании могут быть самолеты нескольких марок и, в то же время, самолет одной марки может принадлежать различным авиакомпаниям, приходим к выводу, что между этими двумя объектами «таблица» имеет место связь типа многие-ко-многим. Подобные отношения не могут непосредственно быть реализованы в реляционной базе данных. Поэтому, выделим связующий объект «таблица» AviaPark с простым ключом Kod для идентификации каждой отдельной записи объекта «таблица» (иначе ключом может быть только совокупность атрибутов N_Comp, N_LA и Data).

Для того, чтобы информация о фирме – разработчике самолета не повторялась многократно в объекте «таблица» авиапарка, введем еще один объект «таблица» (Firma) с информацией о фирме – разработчике. Все выделенные объекты «таблица» имеют связь типа один-ко-многим. Вместе с тем подобная схема позволит облегчить ввод в объект «таблица» авиапарк (AviaPark) (не будет необходимости каждый раз вводить характеристики данного воздушного судна и авиакомпании) и, кроме того, в случае изменения какой-либо характеристики, это изменение производится только в одной строке объекта «таблица» LA, Firma или AirCompany.

Итак, выделим следующие объекты, которым будут соответствовать отдельные объекты «таблица»: авиакомпании, фирмы-производители, летательные аппараты и авиапарк. (Firma – производители, AirCompany – авиакомпании, LA – данные о летательных аппаратах, а также AviaPark - объект «таблица» с информацией об авиапарках компаний) (рис.3,4). Ключами в объекте «таблица» Firma является атрибут N_pr (номер фирмы-производителя), объекте «таблица» AirCompany - атрибут N_Comp (номер авиакомпании), объекте «таблица» LA - атрибут N_LA (номер воздушного судна). Значения ключевым полям (1,2,3, и.т.д.) присваиваются автоматически при вводе записи.

П

Рис.3. Атрибуты объектов - таблиц

оле Vid_LA (объект «таблица» LA) может принимать значения пассажирский или транспортный. В связи с этим значение данного поля можно рассматривать как заранее определенный список и при определении этого поля во вкладке Подстановка/Тип элемента управления, Тип источника строк и Источник строк (рис.5) занесено следующее:

Рис. 5. Диалог задания значений поля Vid_LA в режиме конструктора

Объект «

Рис. 4

таблица» AviaPark содержит информацию о воздушных судах, принадлежащих различным авиакомпаниям и, поэтому, естественным является тот факт, что код авиакомпании и код транспортного средства, связанного с фирмой-производителем каждого должны значиться соответственно в объектах «таблица» AirCompany и Firma, поэтому для полей N_Comp и N_LA источниками должны быть соответствующие объекты «таблица». В дальнейшем для облегчения построения объектов «запрос» на основе исходных объектов «таблица» рекомендуется при определении типа данных для связанных полей использовать “Мастер подстановок” (рис.6), позволяющий определить имя поля связанного объекта «таблица», значение которого будет отображаться при работе с объектами базы данных, построенными на основе подобного объекта «таблица». Фактически в объекте «таблица» храниться числовое значение кода поля. При запуске “Мастера подстановок” во вкладке “Подстановка” автоматически генерируется операторSQL (рис.7).

Рис.6 Рис.7

Например, фактически в объекте «таблица» AviaPark в поле N_Comp хранится значение “1”, при просмотре содержимого этого объекта «таблица», а также объектов, созданных на ее основе («запрос», «форма»), в поле N_Comp отображается значение “Аэрофлот” (табл.7). Ключом в объекте «таблица» AviaPark является атрибут Kod (номер воздушного судна).

Объекты «таблица» созданы в режиме Конструктор, между ними установлены связи в окне “Схема данных” (Сервис/Схема данных), все связи имеют тип “один ко многим”.

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

Рис. 8 Схема данных

Из рисунка следует, что схема данных состоит из четырех объектов «таблица», имеющих связь один ко многим. Так связь объектов «таблица» AirCompany и AviaPark осуществляется по ключевому атрибуту N_Comp (в таблице AirCompany) и неключевому атрибуту N_Comp (в объекте «таблица» AviaPark). Cвязь объектов таблиц LA и AviaPark осуществляется по ключевому атрибуту N_LA (в объекте «таблица» LA) и неключевому атрибуту N_ LA (в объекте «таблица» AviaPark). Cвязь объектов таблиц Firma и LA осуществляется по ключевому атрибуту N_pr (в таблице Firma) и неключевому атрибуту N_pr (в объекте «таблица» LA). Следует отметить, что подобные связанные объекты «таблица» делают невозможным осуществление некорректных действий при обновлении и добавлении информации в базу данных.[4,2].

Примечание.

При использовании полей типа OLE (в рассматриваемом примере это поле Pict_LA таблицы LA), его заполнении заключается в указании полного пути к графическому файлу с фотографией данного типа летательного аппарата. Заполнение полей типа Memo (в рассматриваемом примере это поле Note объекта «таблица» LA) производится путем копирования в блокноте фрагмента описания и вставки этого фрагмента в поле типа Memo соответствующего объекта «таблица».