2020-07-01
80
На основе полученной логической структуры данных строится физическая модель данных. Она представлена на рисунке 2.2.3:
Рис. 2.2.3 Структура базы данных
Стоит дать некоторые комментарии о связях между таблицами. Таблицы World_states и Timetable связаны через атрибуты «City_id» и «From», «To». То есть значениями атрибутов «From», «To» как раз и будут номера городов из таблицы World_states.
Таблица Query связана с таблицей Timetable неявно. Таблица Query содержит одноименный атрибут, который хранит представленный в текстовом виде SQL запрос к таблице Timetable. В общем виде этот запрос выглядит как:
SELECT flight_id, aircraft_id, geometry FROM timetable WHERE (условие)
Условие изменяется и зависит от назначения запроса. Точно также таблица Query связана с таблицей World_cities, меняется лишь шаблон запроса:
SELECT city_id, geometry.point.x as long, geometry.point.y as lat, name FROM timetable WHERE (условие)
Здесь long и lat - это широта и долгота, на которой располагается аэропорт. В таблице они хранятся в одном объекте GEOMETRY, но для отображения аэропортов удобно использовать целочисленные значения.
Архитектура подсистемы
Архитектура подсистемы представлена на рисунке 2.4:
Рис. 2.3 Архитектура подсистемы
Как можно видеть на рисунке, архитектура трехзвенная. Первое звено – это сервер базы данных. Он берет на себя функции хранения данных, обеспечение их безопасности. Второе звено – сервер приложений. Сервер приложений обеспечивает связь с базой данных, выполняет основные операции над данными, работает с геометрией карты. И, наконец, третье звено – это тонкий клиент, с которым будет работать пользователь. Тонкий клиент представляет собой браузер, посылающий запросы на сервер приложений и отображающий полученную с сервера информацию.
| 3. ПРОГРАММНО-ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ | ||||||||||
| ДП 23020165.005.000-12ПЗ | ||||||||||
| Изммм | Лист | № Докум. | Подп. | Дата | ||||||
| Разраб. | Гонтарева | ПРОГРАММНО-ТЕХНОЛОГИЧЕСКИЙ РАЗДЕЛ | Литер. | Лист | Листов Листов | |||||
| Пров. | Лебедев | У | ||||||||
| Гр. АИСТд-51 | ||||||||||
| Утв. | Шеклеин | |||||||||
Выбор средств проектирования
Выбор СУБД
По требованию заказчика в качестве СУБД для данного проекта была выбрана СУБД Oracle. Она приобретена и внедрена компанией, а значит, нет необходимости в дополнительных финансовых затратах на покупку СУБД.
Современная СУБД Oracle это мощный программный комплекс, позволяющий создавать приложения любой степени сложности. Ядром этого комплекса является база данных, хранящая информацию, количество которой за счет предоставляемых средств масштабирования практически безгранично. C высокой эффективностью работать с этой информацией одновременно может практически любое количество пользователей (при наличии достаточных аппаратных ресурсов), не проявляя тенденции к снижению производительности системы при резком увеличении их числа.
СУБД Oracle имеет следующие преимущества:
- Механизмы масштабирования – в СУБД Oracle последней версии позволяют безгранично увеличивать мощность и скорость работы сервера Oracle и своих приложений, просто добавляя новые и новые узлы кластера.
- Полномасштабная поддержка серверных технологий (Java Server Pages, Java-сервлеты, модули Enterprise JavaBeans, интерфейсы прикладного программирования CORBA) за счет встроенной Oracle JavaVM.
- Многоплатформенность - СУБД поставляется практически для всех существующих на сегодня операционных систем. Работая под Sun Solaris, Linux, Windows или на другой операционной системе с продуктами Oracle не будет возникать никаких проблем в работе. СУБД Oracle одинаково хорошо работает на любой платформе.
