Книжный магазин

 

4. ПРОЕКТИРОВАНИЕ ЛОГИЧЕСКОЙ СТРУКТУРЫ БД. 

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

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

     На  этом этапе мы продолжим работу с  локальными концептуальными моделями данных, созданными на предыдущем этапе. Наша задача состоит в доработке этих моделей с целью удаления из них всех элементов, затрудняющих реализацию данных моделей в среде реляционных СУБД. В результате выполнения этих действий структуры концептуальных моделей данных будут изменены таким образом, чтобы полностью отвечать требованиям, выдвигаемым реляционной моделью организации баз данных. Поэтому новые модели более корректно называть логическими моделями данных. Далее созданные логические модели данных будут проверены с использованием правил нормализации и подвергнуты контролю на возможность выполнения всех необходимых пользователям транзакций так, как это указано в спецификациях на создаваемое приложение. Впоследствии проверенные логические модели данных можно будет использовать как прототипы, если это потребуется. В результате выполнения данного этапа будут созданы корректные, полные и точные модели представлений пользователей. Это даст нам прочную основу, необходимую для выполнения следующего этапа, заключающегося в объединении отдельных локальных логических моделей данных, в единую глобальную модель данных всего предприятия.

     Данный  этап включает следующее:

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

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

     3. Проверка модели с помощью  правил нормализации.

     4. Проверка модели в отношении  транзакций пользователей.

     5. Создание диаграмм "сущность-связь".

     6. Определение требований поддержки целостности данных.

     7. Обсуждение разработанных локальных  логических моделей данных с конечными пользователями. ^{[2, c. 277-279]}

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

 

Рисунок 2. - Логическая модель базы данных компьютерного магазина.

 

5. ПРОЕКТИРОВАНИЕ ФИЗИЧЕСКОЙ СТРУКТУРЫ БД. 

     Цель - Создание базовой функциональной схемы реляционной базы данных на основе глобальной логической модели данных.

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

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

• поддерживает ли система определение первичных  ключей, внешних ключей

и альтернативных ключей:

• поддерживает ли система определение обязательных данных (т.е. допускает

ли система  указывать в определении атрибута, что для него запрещено

использование значения NULL);

• поддерживает ли система определение доменов:

• поддерживает ли система определение бизнес-правил предприятия;

• способ определения таблиц базы данных. ^{[2, c. 304-307]}

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

 

Рисунок 3. - Физическая модель базы данных компьютерного магазина.

 

6. ОГРАНИЧЕНИЯ ЦЕЛОСТНОСТИ. 

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

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

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

     По  большому счету все ограничения  можно увидеть на физической модели базы данных (Рисунок 3) там представлены: типы данных и ограничения по вводу. А так же на логической модели (Рисунок 2), на которой видны ключи, как внешние(FK – служащие для связи таблиц), так и первичные (PK – значение, которого используется в качестве уникального идентификатора записи). ^{[3 c. 337-339]} 

 

7. ОРГНАИЗАЦИЯ ВВОДА ДАННЫХ В БД. 

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

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

      Для создания формы нужно открыть  вкладку «Формы» окна базы данных и нажать кнопку «Создать»

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

      Далее при помощи кнопок (перенести все записи) или (перенести выбранную запись) нужно выбрать поля, которые будут отражены в форме (рисунок 4). Нажимаем кнопку «Далее» 

      

 

Рисунок 4. - Создание формы в режиме мастера. Выбор полей для формы.

      Затем нужно выбрать внешний вид  формы, стиль (рисунок 5), задать имя формы и форма готова (Рисунок 6). 

      

 

Рисунок 5. - Выбор стиля оформления формы. 

      

 

Рисунок 6. - Готовая форма таблицы «Книга». 

      Если  автоматическое расположение полей  формы нас не устраивает, и необходимо его изменить. Перейдем в режим конструктора (кнопка на панели инструментов ). Здесь можно менять расположение и размер полей формы по своему усмотрению: достаточно мышкой выделить интересующий объект. (Рисунок 7). 

 

Рисунок 7. - Вид формы в режиме конструктора. 

      Если  мы внесли какие-то изменения теперь их нужно сохранить, через меню Файл → Сохранить.  

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

      - установить курсор на названии книги.

      - выполнить команду меню Правка  → Найти, или воспользоваться кнопкой панели инструментов.

      Для фильтрации данных по полям «№ поставки»:

      - выбираем необходимый код поставки (например, нам интересно, какие  товары были закуплены в 3-ю  поставку) ставим курсор в поле  «№ доставки» - «3», и нажимаем кнопку (или выполняем команду Записи, Фильтр, Фильтр по выделенному). В форме (или таблице) останутся только записи о товарах 3-й поставки;

      - для отмены фильтрации нажимаем  на кнопку  на панели инструментов или выполняем команду Записи, Удалить фильтр. В форме (таблице) появятся все данные. Как правило, фильтрацию удобнее использовать в табличных формах или непосредственно в самих таблицах СУБД Access.

      Режим формы позволяет производить  необходимые вычисления прямо в  поле данных.

      В моем проекте СУБД для книжного магазина в форме «Книги» при заполненных полях «цена» и «кол-во» поле «Общая стоимость товара» автоматически вычисляется. Для автоматизации вычислений необходимо:

      - щелкнуть правой кнопкой мыши  по интересующему полю (в нашем  случае это «Общая стоимость товара») и выбрать пункт «Свойства».

      - откроется окно «Поле: Поле 20». Выбираем вкладку данные и вписываем в поле «Данные» формулу для расчета (Рисунок 8). Нам необходимо, чтобы содержимое поля «цена1» умножалось на содержимое поля «кол-во». 

 

Рисунок 8. - Ввод формулы для расчета.

      - закрываем это окно и сохраняем изменения в таблице.

     Для просмотра созданной формы, как  она будет выглядеть при распечатывании на листе щелкаем по кнопке (Рисунок 9) 

     

 

Рисунок 9. - Предварительный просмотр созданной формы. 

     Через формы так же удобно создавать  новые записи или редактировать старые просто заполняя её.

8. РЕАЛИЗАЦИЯ ЗАПРОСОВ, ПОЛУЧЕНИЕ ОТЧЕТОВ. 

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

      Создадим  запросы на наличие и отсутствие товара.

      Для создания запроса необходимо открыть вкладку «Запросы» окна базы данных, «создание запросов в режиме конструктора» для начала создадим запрос о наличии товара (Рисунок 10) 

 

Рисунок 10. - Запрос на наличие товара в режиме конструктора. 
 
 
 

     Так же запросы можно создавать на языке SQL ради примера создадим на SQL запрос об отсутствующих товарах (Рисунок 11)