Концептуальное проектирование
Первым этапом проектирование базы данных является концептуальное (инфологическое) проектирование. Оно представляет собой построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных.
Чаще всего концептуальная модель базы данных включает в себя:
– описание информационных объектов или понятий предметной области и связей между ними;
– описание ограничений целостности, то есть требований к допустимым значениям данных и к связям между ними.
Создадим концептуальную схему базы данных (рис. 4.1).
Рисунок 4.1 – Концептуальная схема базы данных
Логическое проектирование
Логическое проектирование – создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.
Преобразование концептуальной модели в логическую модель, как правило, осуществляется по формальным правилам. На этапе логического проектирования учитывается специфика конкретной модели данных, но может не учитываться специфика конкретной СУБД.
Создадим логическую схему для реляционной базы данных.
|
|
|
Физическое проектирование
Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. д.
Используя СУБД MicrosoftAccess, создадим базу данных (рис. 4.2).
Рисунок 4.2 – Схема данных базы MicrosoftAccess
На рисунке 4.2 видим структуру созданной базы данных. Таблицы связаны между собой ключевыми полями и связями «один-ко-многим». Связь «один-ко-многим» означает, что, например, у одного отделения почтовой связи может быть только один адрес, но на одном адресе может находиться несколько отделений.
Создана дополнительная таблица Users для реализации многопользовательского доступа к базе данных через интерфейс пользователя.
Следующим пунктом является заполнение базы данных. На данном этапе были по достоинству оценены плюсы реляционной модели данных: при заполнении таблицы «ИнтернетКанал» в поле «Название оператора» вводится только индекс оператора, в то время как в таблице «Оператор» содержится 8 пунктов с названиями операторов.
|
|
|
Оценить правильность проектирования базы данных можно путём составления запроса. Выполняется он на языке структурированных запросов SQL (StructuredQueryLanguage).
Для начала выполним запрос на выборку, где выведем основные столбцы базы данных со всеми записями. Сделать это можно, используя «Конструктор запросов» или «Режим SQL» в СУБД MicrosoftAccess. Текст запроса представлен в приложении А.
Результат выполнения запроса можно увидеть на рисунке 4.3. С помощью запроса выведены все данные таблицы, значит база данных спроектирована правильно.
Рисунок 4.3 – Результат выполнения запроса
Далее, создадим запрос, который покажет все отделения почтовой связи, находящиеся в городе Томск, имеющие 3 операционных окна и выведет только название ОПС, его адрес и телефон. Результат представлен на рисунке 4.4.
Рисунок 4.4 – Результат выполнения запроса «Томск, 3 окна»
Дата добавления: 2018-06-27; просмотров: 629; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!