Физическая модель данных

Выбор СУБД

ФИЗИЧЕСКАЯ РЕАЛИЗАЦИЯ ПРИЛОЖЕНИЯ

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

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

В качестве такой реляционной СУБД выбрана СУБД VisualFoxPro 9.0. Обоснованием данного выбора является следующее:

– быстро и удобно различными способами создаётся БД любой сложности;

– содержит набор инструментов для создания таблиц и отношений между связанными таблицами;

– содержит средства администрирования базы данных;

– имеет развитый пользовательский интерфейс, который позволяет получить доступ к информации, хранящейся в базе

– имеет средства разработки приложений, использующих базы данных;

– есть возможность создавать "клиент-серверное" приложение;

– позволяет переносить данные на платформу другой СУБД;

– содержит полнофункциональный язык объектно-ориентированного программирования. [4]

Имея встроенный язык SQL, СУБД VisualFoxPro позволяет создать базу данных, применив программный код, предложенный и описанный в подразделе 2.4. Единственным дополнением здесь будет - это создание самой базы данных, которое выполняется в самом начале. Создаётся база данных с именем Provider, рисунок 3.1.

Рис 3.1 – Создание базы данных Provider

Итак, для создания базы данных и входящих в нее таблиц с соответствующими связями используются команды CREATEDATABASE и CREATETABLE (для модификации – ALTERTABLE), которые относятся к подъязыку определения данных (DDL) языка SQL.

В результате создания базы данных «Интернет-провайдер» и входящих в нее таблиц схема базы данных будет выглядеть, как показано на рис 3.2.

Рис 3.2 – Схема базы данных Provider

Проверка целостности данных осуществляется средствами базы данных и определена согласно описаниям в подразделе 2.4. Как определены условия целостности, данных показано на рисунке 3.3.

Рис 3.3 – Определение условий целостности данных

Из рисунка 3.3 видно, что при попытке обновить значение первичного ключа в родительской таблице произойдет каскадное обновление соответствующих значений внешнего ключа в дочерней таблице. При попытке удаления записи в родительской таблице будет запрещено выполнение операции «удаление» до тех пор, пока хотя бы одна запись в дочерней таблице ссылается на соответствующую запись в родительской таблице. При попытке вставки записи в дочернюю таблицу операция «вставить» будет запрещена до тех пор, пока в родительской таблице не будет данного значения, используемого как значение внешнего ключа в дочерней таблице.

Дата добавления: 2015-07-13