Пользователи
Рис. 1. Структура банка данных
На рис. 1 прямоугольниками показаны элементы банка данных, а двунаправленными стрелками - связи между ними.
База данных (БД) - структурированная совокупность данных, поддерживаемых в актуальном состоянии и отображающих свойства объектов предметной области (ПО). Поддержание БД в актуальном состоянии означает, что все изменения в реальных объектах находят свое отражение в БД.
БД содержит сами данные и описания структуры этих данных.
Система управления базами данных (СУБД) - сложная программная система накопления и манипулирования данными.
Специалисты - лица различной квалификации, занимающиеся разработкой БД. К их числу следует отнести администратора базы данных (АБД) - лицо или группу лиц, отвечающих за структуру БД, за ее сохранность, и внешних пользователей - специалистов, использующих некоторые части БД путем написания прикладных программ.
Прикладная программа - программа, осуществляющая доступ к тем или иным данным из БД. Каждой прикладной программе СУБД предоставляет связь с БД, так как располагает средствами непосредственного доступа к ней.
Пользователи - лица, выполняющие прикладные программы, специалисты в конкретной предметной области.
Архитектура СУБД может быть представлена следующим образом (рис. 2):
ЯОД
ЯМД
Рис. 2. Архитектура СУБД
Язык описания данных (ЯОД) - средства описания данных в БД и связей между ними. Средствами этого языка описывается структура БД, форматы записей, пароли, защищающие данные.
Язык манипулирования данными (ЯМД) - язык для выполнения операций над данными, позволяющий менять их состояние.
В современных СУБД язык трансформировался в средства визуальной (зримой, наглядной) разработки программ. Для этой цели в составе СУБД имеются редакторы экранных форм, отчетов. “Кирпичиками” (инструментами) таких редакторов являются поля различных видов (поля ввода, поля вывода, вычисляемые поля), процедуры обработки различных типов (формы ввода, таблицы, отчеты, запросы).
На основании созданных пользователем объектов программы-генераторы формируют исполнимый код.
В данном учебном пособии излагаются этапы проектирования и разработки приложения баз данных. Для построения полноценного приложения баз данных необходимо выполнение всех этих этапов. Различные этапы проектирования и разработки иллюстрируются задачей, в которой рассматриваются учителя, классы, ученики и изучаемые ими предметы.
При проведении различных этапов, связанных с проектированием, будем использовать CASE-средства (сокращение от Computer Aided Software Engineering), которые позволяют автоматизировать создание информационных систем на протяжении всего жизненного цикла. Имеются CASE-средства для моделирования, проектирования, разработки, тестирования и т.д.
2. Проектирование логической структуры базы данных
Основная цель проектирования БД – это сокращение избыточности хранимых данных, и, следовательно, экономия объема используемой памяти, уменьшение затрат на многократные операции обновления избыточных копий и устранение возможности возникновения противоречий из-за хранения в разных местах сведений об одном и том же объекте.
Предположим, что проектирование базы данных "Питание" начинается с выявления всех атрибутов (табл. 1).
Таблица 1
Наз- вание блюда |
Вид |
Ре- цепт |
Чис- ло пор- ций |
Дата рас- хода |
Название продукта |
Число калорий |
Мас- са про- дукта в блюде |
Наз- вание постав- щика |
Город |
Страна |
Масса поставки |
Цена поставки |
Дата поставки продукта |
Таблица представляет собой корректное отношение. Его называют универсальным отношением проектируемой БД. В одно универсальное отношение включаются все представляющие интерес атрибуты, и оно может содержать все данные, которые предполагается размещать в БД в будущем. Универсальное отношение может использоваться в качестве отправной точки при проектировании БД.
Начинающий проектировщик будет использовать отношение "Питание" в качестве завершенной БД. Действительно, зачем разбивать отношение "Питание" на несколько более мелких отношений, если оно заключает в себе все данные? А разбивать надо потому, что при использовании универсального отношения возникает несколько проблем:
1. Избыточность. Данные почти всех столбцов многократно повторяются. Повторяются и некоторые наборы данных (Блюдо-Вид-Рецепт, Продукт-Калорийность, Поставщик-Город-Страна). Нежелательно повторение рецептов. И уж совсем плохо, что все данные о блюде повторяются каждый раз, когда это блюдо включается в меню.
2. Аномалии обновления. Вследствие избыточности можно обновить адрес поставщика в одной строке, оставляя его неизменным в других. Если поставщик кофе сообщил о своем переезде в Харбин, и была обновлена строка с продуктом “кофе”, то у поставщика "Хуанхэ" появляется два адреса, один из которых не актуален. Следовательно, при обновлениях необходимо просматривать всю таблицу для нахождения и изменения всех подходящих строк.
3. Аномалии включения. В БД не может быть записан новый поставщик ("Няринга", Вильнюс, Литва), если поставляемый им продукт (Огурцы) не используется ни в одном блюде. Можно, конечно, поместить неопределенные значения в столбцы Блюдо, Вид, Порций и Масса (г) для этого поставщика. Но если появится блюдо, в котором используется этот продукт, не забудем ли мы удалить строку с неопределенными значениями?
По аналогичным причинам нельзя ввести и новый продукт (например, Баклажаны), который предлагает существующий поставщик (например, "По-лесье"). А как ввести новое блюдо, если в нем используется новый продукт (Крабы)?
4. Аномалии удаления. Другая проблема возникает при необходимости удаления всех продуктов, поставляемых данным поставщиком или всех блюд, использующих эти продукты. При таких удалениях будут утрачены сведения о таком поставщике.
Цель логического проектирования БД – создание набора отношений, описывающих БД, обеспечивающих минимальную избыточность и содержащих как можно меньше аномалий всякого рода.
Многие проблемы этого примера исчезнут, если выделить в отдельные таблицы сведения о блюдах, продуктах и их поставщиках, а также создать связующие таблицы "Состав" и "Поставки" (Рис. 3).
