Разработка физической структуры базы данных. Правила перехода от логической реляционной структуры к физической

Лекция 6.

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

Итак, займемся разработкой физической структуры базы данных

Физическое моделирование базы данных – это способ размещения информации на машинных носителях. 

Правила перехода от логической реляционной структуры к физической заключаются в следующем:

 каждая реляционная таблица превращается в таблицу базы данных; каждый столбец таблицы -   в поле таблицы;  каждая строка таблицы  -  в запись таблицы. 

В процессе физического проектирования реляционной базы данных необходимо: присвоить имена таблицам;  присвоить имена полям таблиц.

Соответствие документов и таблиц базы данных

Таблицы базы данных заполняются на основе входных (первичных) документов. Например, в таблице ПРЕДПРИЯТИЯ имена полей КОД_ПРЕД и НАИМ_ПРЕД.

Подробно конструирование таблиц для реляционной базы данных будет рассмотрено нами далее.

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

Итак, будем заполнять таблицы конкретными исходными данными. Для упрощения решаемых задач сократим количество реквизитов в исходных таблицах. На основании этих данных нам будет легче произвести вручную расчёты для задачи 1 и задачи 2, чтобы проверить правильность компьютерного решения.

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

Внимание!!! Заполнение таблиц исходными данными в контрольной работе должно осуществляться в полном соответствии с ограничениями, допущениями и особенностями программного обеспечения.

Для нашего примера таблицы, заполненные конкретными значениями, будут выглядеть так:

                         ПРЕДПРИЯТИЯ                                         НАЛОГИ

                              ПЛАН                                                           ПЛАТЕЖИ

СПЕЦИФИКАЦИЯ ПЛАТЕЖЕЙ

Примечание: данные задаем произвольно по количеству значений и содержанию с учётом ограничений.

По приведенным исходным данным выполним вручную решение поставленных задач наш контрольный пример.

Первая наша задача сформулирована так:

Анализ оплаты налогов по заданному предприятию.

Отберём платёжные поручения для заданного предприятия «Восток».

По отобранным платёжным поручениям вычисляем общие суммы оплаты по каждому виду налога.

Затем найдём отклонение между фактической и плановой суммой по каждому виду налога для заданного предприятия.

В результате получим:

Анализ оплаты налогов по предприятию Восток

Вторая наша задача: Выявление недоплат налогов на заданную дату по всем предприятиям.

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

Найдём недоплаты (план - факт) > 0.

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

Недоплаты предприятий на 17.03.14

Итак, мы решили задачу вручную. Это возможно только в том случае, если данных мало. Поэтому давайте выберем для решения подобных задач на компьютере систему управления базы данных (СУБД) Access и поговорим немного об этой СУБД.

СУБД Access является универсальным средством для создания и обслуживания баз данных, обеспечения доступа к данным, и их обработки. К тому же это одна из самых распространенных СУБД, так как она является частью одного из самых распространённых в нашей стране программных продуктов, пакета прикладных программ Microsoft office. 

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

Реляционная база данных - это совокупность взаимосвязанных двумерных