Этапы проектирования и создания базы данных (БД) с среде Access

В качестве основного источника информации в рамках текущего блога будет использоваться литература: Юрий Бекаревич и Нина Пушкина "Самоучитель Access 2010 и 2013"

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

Определение состава и структуры данных, которые должны быть загружены в БД, осуществляется на основе анализа предметной области. Структура данных предметной области может отображаться информационно-логической моделью (ИЛМ). Если при построении такой модели обеспечены требования нормализации данных и она, соответственно, представлена в каноническом виде, далее легко определяется проект логической структуры нормализованной базы данных. На основе канонической модели можно создать реляционную базу без дублирования данных.

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

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

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

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

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

Информационные объекты

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

Информационный объект имеет множество реализаций - экземпляров объекта.

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

Требования нормализации

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

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

Замечание

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

Информационный анализ и определение логической структуры информации

Информационный анализ включает:

• структурирование информации предметной области
• формализацию и моделирование данных

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

Структурирование информации

Рассмотрим структурирование информации применительно к организационно-экономической сфере. Определим важнейшие виды структурных единиц информации:

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

1. реквизит-признак позволяет выделить (идентифицировать) объект из множества однотипных объектов (как правило, символьное представление)

реквизит-основание содержит количественную характеристику объекта, процесса или другой сущности, определяющую их состояние (как правило, числовое значение)

• составная единица информации (СЕИ) - логически взаимосвязанная совокупность реквизитов

Документ является примером составной единицы информации. Семантика и размещение реквизитов в форме документа определяют роль реквизитов в структуре информации, содержащейся в документе.

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

Выделение информационных объектов

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

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

1. Определяются функциональные зависимости между реквизитами документа. Для этого анализируется роль реквизитов в структуре информации документа. Сначала целесообразно выявить реквизит (один или несколько), который играет роль общего идентификатора всей информации документа. Как правило, к таким реквизитам относятся номер документа, идентификатор подразделения предприятия, выпускающего документ, период действия оформления документа и т.п. От такого идентификатора документа будут функционально полно зависимыми некоторые описательные реквизиты в общей части документа. В результате для каждого определяемого реквизита должны бть выявлены реквизиты (ключевые), которые в совокупности однозначно его определяют (одному значению ключа соответствует одно значение описательного реквизита).
2. В результате просмотра выявленных функциональных зависимостей выбираются зависимые реквизиты и для каждого из них устанавливаются все его ключевые реквизиты, т.е. те (один или несколько), которые в совокупности определяют его однозначно.
3. Группируются реквизиты, одинаково зависимые от ключевых реквизитов. Полученные группы зависимых реквизитов вместе с ключевыми реквизитами образуют реквизитный состав соответствующих информационных объектов. Если в группе несколько ключевых реквизитов, то они являются составным ключом информационного объекта.

После выделения информационных объектов необходимо сформировать их окончательное описание. В таком описании кроме состава реквизитов и указания ключа может быть представлена также семантика информационных объектов -их смысловое определение.

Замечание

Обычно при использовании приведенных правил сразу оказываются выделенными объекты, играющие роль связки между объектами, находящимися в отношении "многие-ко-многим" (M:N). Соответственно, в модели можно ограничиваться рассмотрением только одно-многозначных связей. 

Типы связи информационных объектов

• одно-однозначные (1:1)
• одно-многозначные (1:М)
• много-многозначные (М:М)

Создание базы данных

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

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

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

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

Внимание! 

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

Окно Access

Создание новой пустой базы данных приводит к открытию окна Access

Три основных компонента пользовательского интерфейса формируют среду, в которой созда ются и используются БД:

• Лента - полоса в верхней части окна приложения, содержащая группы команд выбранной вкладки. Вкладки ленты объединят логически связанные команды, ориентированные на задачу. Четыре стандартные вкладки - Главная (Home), Создание (Create), Внешние данные (External Data) и Работа с базами данных (Database Tools)
• Представление Backstage - набор команд на вкладке Файл (File)
• Область навигации - область в левой части окна, предназначенная для работы с объектами БД.

Создание таблицы БД

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

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

Схема данных в Access

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

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

Создание схемы данных

Создание схемы данных начинается с выполнения команды Схемы данных (Relationships) в группе Отношения (Relationships) на вкладке ленты Работа с базами данных (Dаtabase Tools). В результате выполнения этой команды открывается окно схемы данных и диалоговое окно Добавление таблицы (Show Table), в которой осуществляется выбор таблиц, включаемых в схему. Диалоговое окно Добавление таблицы откроется автоматически, если в БД ещё не определена ни одна связь. Если окно не открылось, на ленте Работа со связями | Конструктор (Relationship Tools | Design) в группе Связи нажмите кнопку Отобразить таблицу.

Включение таблиц в схему данных

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

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

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

Запросы

Запросы являются основным инструментом выборки, обновления и обработки данных в таблицах БД.

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

В Access может быть создано несколько видов запроса: 

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

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

С помощью запроса можно выполнить следующие виды обработки данных:

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

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

Конструирование запросов

1. Для создания запроса в окне БД выберите вкладку лент - Создание(Create)  и  в группе Запросы(Queries) нажмите кнопку  Конструктор запросов(Query Design). Откроется пустое окно запроса на выборку в режиме конструктора -  ЗапросN(QueryN) и диалоговое окно Добавление таблицы(Show Table) 
2. В окне Добавление таблицы (Show Table) выберите ТОВАР и нажмите кнопку Добавить (Add). Выбранная таблица будет отображена в области схемы данных запроса. Закройте окно Добавление таблицы (Show Table), нажав кнопку Закрыть (Close)/

В результате выполненных действий в окне конструктора запросов в верхней панели появится схема данных запроса, которая включает выбранные для данного запроса таблицы. В данном случае одну таблицу ТОВАР. Таблица представлена списком полей. Первая строка в списке полей таблицы, отмеченная звездочкой (*) , обозначает все множество полей таблицы. Нижняя панель является бланком запроса, который нужно заполнить. 

Кроме того, на ленте появляется и автоматически активизируется новая вкладка Работа с запросами | Конструктор (Query Tools | Design), на котором цветом выделен тип созданного запроса - Выборка (Select). Таким образом, по умолчанию всегда создается запрос на выборку. Команды этой вкладки представляют инструментарий для выполнения необходимых действий при создании запроса. Эта вкладка открывается, когда в режиме конструктора создается новый запрос или редактируется существующий.

Параметры в запросах 

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

Групповые операции в запросах 

Групповые операции позволяют выделить группы записей с одинаковыми значениями в указанных полях и вычислить итоговые данные для каждой из групп по другим полям, используя одну из статистических функций. Статистические функции применимы, прежде всего, к полям с типом данных Числовой, Денежный, Дата/Время.

В Access предусматривается девять статистических функций: 

• Sum - сумма значений некоторого поля для группы
• Avg -  среднее от всех значений поля в группе
• Max, Min - максимальное, минимальное значение поля в группе
• Count - число значений поля в группе без учета пустых значений
• StDev - среднеквадратичное отклонение от среднего значения поля в группе
• Var - дисперсия значения поля в группе
• First и Last - значение поля из первой или последней записи в группе

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

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

Формы

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

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

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

• Макет (Format) - представляет свойства. ориентированные на определение внешнего вида формы или ее элементов
• Данные (Data) - представляет свойства для определения источника данных формы или ее элементов, режима использования формы (только ввод, разрешение на изменение, добавление, удаление и т.п.)
• События (Event) - событиями называют определенные действия, возникающие при работе с конкретным объектом или элементом: нажатие кнопки мыши, изменение данных, до обновления, после обновления, открытие или закрытие формы и т.д. Они могут быть инициированы пользователем или системой. С событием может связываться макрос или процедура обработки события на языке VBA, выполняющая некоторые действия или рассчитывающая значения. Например, в процедуре можно организовать открытие связанной формы, обновление данных таблицы расчетными значениями, печать формы, вывод отчета. Запрограммировав в процедурах вызов различных объектов БД, можно автоматизировать выполнение задач приложения.

Формы в Access могут быть представлены в трех режимах.

• Режим формы (Form View) предназначен для ввода, просмотра и корректировки данных таблиц. на которых основана форма.
• Режим макета (Layout View) обеспечивает просмотр данных почти в таком виде, в каком они отображаются в режиме формы, и в то же время позволяет изменять форму. В этом режиме элементы формы становятся выделяемыми, их можно перетаскивать в другие места, редактировать содержимое надписей полей и т.д. Режим макета позволяет удобно настраивать внешний вид формы и может использоваться для внесения  большинства структурных изменений. В Access 2010 появилась возможность в режиме макета выполнять действия. ранее доступные только в режиме конструктора. В режиме макета стала доступной лента Конструктор (Design). Если некоторую задачу невозможно выполнить в режиме макета, следует переключиться в режим конструктора. В ряде случаев в Access отображается сообщение о том, что для внесения изменений надо переключиться в режим конструктора.
• Конструктор (Design View) предназначен для разработки формы с помощью полного набора инструментов, обеспечивающего более детальную проработку структуры формы, использование всех элементов управления. В этом режиме форму можно разработать с нуля или доработать ее после создания мастером. Просмотр данных при внесении изменений в этом режиме не предусматривается.

Разработка интерфейса для ввода, просмотра и корректировки документов

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

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

При конструировании интерфейса пользователя могут использоваться макросы или процедуры VBA для обработки событий, инициируемых пользователем в процессе работы с формой. Для формы и ее элементов управления определен набор типовых событий. Такие связанные с полем события как Изменение (On Change), До обновления (Before Update), После обновления (After Update) или связанные с записью события Удаление (Delete), До обновления (Before Update), После обновления (After Update) часто используются для подключения процедур, обеспечивающих автоматический перерасчет (изменение) показателей в таблицах.

При создании некоторых элементов формы автоматически формируются типовые процедуры обработки событий. Таким элементом является, например, кнопка. С ее событием Нажатием кнопки (On Click) связывается выполнение таких категорий действий как: 

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

Этапы разработки интерфейса

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

Технология поддержания такой БД в актуальном состоянии требует обеспечения процесса ввода оперативных данных и обновления существующих данных.

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

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

В процессе разработки технологии загрузки БД и проектирования форм целесообразно определить:

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

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

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

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

- в главную форму обязательно надо вводить ключевые поля таблицы-источника данных (например, идентификатор документа "Договор" - номер договора)

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

Определение последовательности загрузки таблиц с документов

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

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

В соответствии с этими требованиями можно рекомендовать в практических приложениях предусмотреть сначала ввод в БД, а затем данных плановых и оперативно-учетных документов Это связано с тем, что таблицы с плановыми и оперативно-учетными данными в схеме данных являются подчиненными по отношению к таблицам справочных данных, которые, как правило, находятся на верхнем уровне.

Отчеты

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

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

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

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

Основы конструирования отчетов

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

Назначение  каждого из разделов:

• Заголовок отчета (Report Header) обычно включает эмблему компании, название отчета, дату. Заголовок отображается перед верхним колонтитулом только один раз в начале отчета
• Верхний колонтитул (Page Header) отображается вверху каждой страницы и используется в случае, когда нужно, чтобы название отчета и другая общая информация повторялись на каждой странице
• Заголовок группы (<имя поля > Header) используется при группировке записей отчета для вывода названия группы и однократного отображения полей, по которым производится группировка. Отображается перед каждой новой группой записей. Например, если отчет сгруппирован по покупателям, в заголовке группы можно указать название покупателя, а также адрес, телефон и другие реквизиты. Допускается до 10 уровней группировки выводимых записей
• Область данных (Detail) отображает записи из источника данных, составляющие основное содержание отчета
• Примечание группы (<имя поля > Footer) используется для отображения итогов и другой сводной информации по группе в конце каждой группы записей. Если поместить в примечание группы вычисляемый элемент управления, использующий статистическую функцию Sum, сумма будет рассчитываться для текущей группы
• Нижний колонтитул (Page Footer) применяется для нумерации страниц и отображения другой информации внизу каждой страницы
• Примечание отчета (Report Footer) служит для отображения итогов и другой сводной информации по всему отчету один раз в конце отчета. Если в примечании отчета поместить вычисляемый элемент управления, использующий статистическую функцию Sum, сумма рассчитывается для всего отчета.

Принципы организации баз данных

Классификация БД

По технологии обработки БД подразделяются на централизованные и распределённые.

Централизованная БД хранится в памяти одной вычислительной системы. Эта вычислительная система м.б. мэйнфреймом - тогда доступ к ней организуется с использованием терминалов - или файловым сервером локальной сети ПК

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

По способу доступа к данным БД разделяются на БД с локальным доступом и БД с сетевым доступом.

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

Централизованные БД с сетевым доступом могут иметь следующую архитектуру:

• файл-сервер
• клиент-сервер БД
• "тонкий клиент" - сервер приложений - сервер БД (трехуровневая архитектура)

Файл-сервер. Архитектура БД с сетевым доступом предполагает выделение одной из машин в качестве центральной (файловый сервер). На этот компьютер устанавливается операционная система (ОС) для выделенного сервера (например, Windows Server). На нём же хранится совместно используемая централизованная БД в виде одного или группы файлов. Все другие компьютеры выполняют функции рабочих станций. Файлы БД в соответствии с пользовательскими запросами передаются на рабочие станции, где и производится обработка информации. При большой интенсивности доступа к одним и тем же данным производительность информационной системы падает. Пользователи могут создавать также локальные БД на рабочих станциях.

Клиент-сервер. В этой архитектуре на выделенном сервере, работающем под управлением серверной операционной системы, устанавливается специальное программное обеспечение (ПО) - сервер БД, например Microsoft SQL Server или Oracle. СУБД подразделяется на две части: клиентскую и серверную. Основа работы сервера БД - использование языка запросов (SQL). Запрос на языке SQL, передаваемый клиентом (рабочей станцией) серверу БД. порождает поиск и извлечение данных на сервере. Извлеченные данные транспортируются по сети от сервера к клиенту. Тем самым, количество передаваемой по сети информации уменьшается во много раз. 

Трехуровневая архитектура функционирует в Интернет-сетях. Клиентская часть ("тонкий клиент"), взаимодействующая с пользователем, представляет собой HTML-страницу в Web-браузере или Windows-приложение, взаимодействующее с Web-сервисами. Вся программная логика вынесена на сервер приложений, который обеспечивает формирование запросов к БД, передаваемых на выполнение серверу БД. Сервер приложений может быть Web-сервером или специализированной программой (например, Oracle Forms Server).

Ранние подходы к организации БД

Иерархические БД

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

Иерархическая БД состоит из упорядоченного набора нескольких экземпляров одного типа дерева. Автоматически поддерживается целостность ссылок между предками и потомками. Основное правило: никакой потомок не может существовать без своего родителя

Типичным представителем (наиболее известным и распространённым) является Information Managment System (IMS) фирмы (IBM). Первая версия появилась в 1968г. До сих пор поддерживается много БД этой системы.

Сетевые БД

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

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

Типичным представителем является Integrated Database Management System (IDMS), предназначенная для использования на машинах основного класса фирмы IBM под управлением большинства операционных систем.

Современные БД

Реляционные системы

Реляционная модель данных основывается на математических принципах, вытекающих непосредственно из теории множеств и логики предикатов. Эти принципы впервые были применены в области моделирования данных в конце 1960-х гг. доктором Е.Ф. Коддом, в то время работавшим в IBM, а впервые опубликованы - в 1970-х г.

Доктор Кодд определил 12 правил реляционной модели (которые называют 12 правилами Кодда).

12 правил Кодда

       0. Реляционная СУБД должна быть способна полностью управлять БД через ее      реляционные возможности

1. Информационно правило - вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться строго как значения в таблицах
2. Гарантированный доступ - любое значение в реляционной БД должно быть гарантированно доступно для использования через комбинацию имени таблицы, значения первичного ключа и имени столбца
3. Поддержка пустых значений (null value) - СУБД должна уметь работать с пустыми значениями (неизвестными или неиспользованными значениями), в отличие от значений по умолчанию и независимо для любых доменов
4. Онлайновый реляционный каталог - описание БД и ее содержания должны быть представлены на логическом уровне как таблицы, к которым можно применять запросы, используя язык БД
5. Исчерпывающий язык управления данными - по крайней мере, один из поддерживаемых языков должен иметь четко определенный синтаксис и быть всеобъемлющим. Он должен поддерживать описание структуры данных и манипулирование ими, правила целостности, авторизацию и транзакции.
6. Правило обновления представления (views) - все представления, теоретически обновляемые, могут быть обновлены через систему
7. Вставка, обновление и удаление - СУБД поддерживает не только запрос на отбор данных, но и вставку, обновление и удаление
8. Физическая независимость данных - на программы-приложения и специальные программы логически не влияют изменения физических методов доступа к данным и структур хранилищ данных
9. Логическая независимость данных - на программы-приложения и специальные программы логически не влияют, в пределах разумного, изменения структур таблиц
10. Независимость целостности - язык БД должен быть способен определять правила целостности. Они должны сохраняться в онлайновом справочнике, и не должно существовать способа их обойти
11. Независимость распределения - на программы-приложения и специальные программы логически не влияет, первый раз используются данные или повторно
12. Неподрывность - невозможность обойти правила целостности, определенные через язык БД, использованием языков низкого уровня

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

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

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

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

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

Формулируя принципы реляционной модели, доктор Кодд выбрал термин "отношение" (relation), потому что, по его мнению, этот термин однозначен ( в то время как, например, термин "таблица" имеет множество различных видов - таблица в тексте, электронная таблица и пр.). Весьма распространено следующее заблуждение: реляционная модель названа так потому, что она определяет связи между таблицами. На самом деле, название этой модели происходит от отношений (таблиц БД), лежащих в её основе.

Каждая строка, содержащая данные, называется кортежем, каждый столбец отношения называется атрибутом (на уровне практической работы используются термины "запись" и "поле")

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

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

Атрибуты сущности бывают:

1. Идентифицирующие и описательные. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов.Остальные атрибуты называются описательными.
2. Простые и составные. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких компонентов, возможно, принадлежащих разным типам данных. решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от особенностей процессов его использования и может быть связано с обеспечением высокой скорости работы с большими БД.
3. Однозначные и многозначные - могут иметь соответственно одно или много значений для каждого экземпляра сущности
4. Основные и производные. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов.

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

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

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

Существует несколько типов связей между двумя сущностями: это связи "один к одному", "один ко многим" и "многие ко многим".

Каждая связь в реляционной модели характеризуется именем, обязательностью, типом и степенью. Различают факультативные и обязательные связи. Если сущность одного типа оказывается по необходимости связанной с сущностью другого типа, то между этими типами объектов существует обязательная связь (обозначается двойной линией). Иначе связь является факультативной.

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

Диаграмма "сущности-связи" (Entity-Relationship diagrams, или E/R diagram) служит для описания схемы базы на концептуальном уровне проектирования. Метод был предложен в 1976г. Питером Пин Шань Ченом. На диаграммах "сущности-связи" сущности изображаются в виде прямоугольников, атрибуты - в виде эллипсов, а связи - в виде ромбов

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

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

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

В рамках реляционной модели данных Э.Ф.Коддом были разработаны принципы нормализации отношений и предложен механизм, позволяющий любое отношение преобразовать к третьей нормальной форме.

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

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

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

Отношение приведено к 1НФ, если все его атрибуты - простые, т.е. значение атрибута не должно быть множеством или повторяющейся группой. 

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

Вторая нормальная форма (2НФ) применяется к отношениям с составными ключами (состоящими из двух и более атрибутов) и связана с понятием функциональной зависимости.

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

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

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

Третья нормальная форма (3НФ) связана с понятием транзитивной зависимости. Пусть А, В, С - атрибуты некоторого отношения. При этом А -> В и В -> С, но обратное соответствие отсутствует, т.е. С не зависит от В или В не зависит от А. Тогда говорят, что С транзитивно зависит от А (А -> -> С)

В  третьей нормальной форме устраняются атрибуты, которые зависят от атрибутов, не входящих в уникальный ключ. Эти атрибуты являются основой отдельной сущности.

Отношение находится в 3НФ. если оно находится во 2НФ и не имеет атрибутов, не входящих в первичный ключ и находящихся в транзитивной зависимости от первичного ключа. 

Существуют также нормальная форма Бойса-Кодда (НФБК), 4НФ и 5НФ. Однако наибольшее значение имеет 1НФ, т.к. последующие НФ связаны с понятием о составных ключах и сложных зависимостях от ключей, а на практике встречаются обычно более простые случаи.

Моделирование структуры базы данных при помощи алгоритма нормализации имеет серьезные недостатки:

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

В реальном проектировании структуры БД применяются другой метод - так называемое семантическое моделирование. Семантическое моделирование представляет собой моделирование структуры данных, опирающееся на смысл этих данных. В качестве инструмента семантического моделирования используются различные варианты диаграмм "сущность-связь (ERD)" с построением концептуальной модели БД.

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

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

Соблюдение условий ссылочной целостности в реляционной БД

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

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

Для родительской таблицы: 

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

Для дочерней таблицы:

• Вставка. Нельзя вставить запись в дочернюю таблицу, если для новой записи значение внешнего ключа некорректно. Операция может привести к нарушению ссылочной целостности.
• Обновление. При обновлении записи в дочерней таблице можно попытаться некорректно изменить внешнего ключа. Операция может привести к нарушению ссылочной целостности. 
• Удаление. При удалении записи в дочерней таблице ссылочная целостность не нарушается. 

Таким образом, ссылочная целостность в принципе может быть нарушена при выполнении одной из четырех операций: 

1. Обновление записей в родительской таблице
2. Удаление записей в родительской таблице
3. Вставка записей в дочерней таблице
4. Обновление записей в дочерней таблице

Основные стратегии поддержания ссылочной целостности

Существуют две основные стратегии поддержания ссылочной целостности

RESTRICT (ОГРАНИЧИТЬ) - не разрешать выполнение операции, приводящей к нарушению ссылочной целостности.

CASCADE (КАСКАДНОЕ ИЗМЕНЕНИЕ) - разрешить выполнение требуемой операции, но внести при этом необходимые изменения в связанных таблицах так, чтобы не допустить нарушения ссылочной целостности и сохранить все имеющиеся связи. Изменение начинается в родительской таблице и каскадно выполняется в дочерних таблицах. В реализации этой имеется одна тонкость, заключающаяся в том, что дочерние таблицы сами могут быть родительскими для некоторых третьих таблиц. При этом может дополнительно потребоваться выполнение какой-либо стратегии и для этой связи и т.д. Если при этом какая-либо из каскадных операций (любого уровня) не может быть выполнена, то необходимо отказаться от первоначальной операции и вернуть базу данных в исходное состояние. Это сложная стратегия, но она не нарушает связей между родительскими и дочерними таблицами.
Эти стратегии являются стандартными и присутствуют во всех СУБД, в которых имеется поддержка ссылочной целостности.

Дополнительные стратегии поддержания ссылочной целостности

IGNORE (ИГНОРИРОВАТЬ) - разрешить выполнять операцию без проверки ссылочной целостности. В этом случае в дочерней таблице могут появляться некорректные значения внешних ключей, вся ответственность за целостность БД ложится на программиста или пользователя.

SET NULL (ЗАДАТЬ ЗНАЧЕНИЕ NULL) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на null-значения. Эта стратегия имеет два недостатка. Во-первых, для нее требуется разрешение на использование null-значений. Во-вторых, записи дочерней таблицы теряют связь с записями родительской таблицы. Установить, с какой записью родительской таблицы были связаны измененные записи дочерней таблицы, после выполнения операции уже нельзя.

SET DEFAULT (ЗАДАТЬ ЗНАЧЕНИЕ ПО УМОЛЧАНИЮ) - разрешить выполнение требуемой операции, но все возникающие некорректные значения внешних ключей изменять на некоторое значение, принятое по умолчанию. Достоинство этой стратегии по сравнению с предыдущей в том, что она позволяет не пользоваться  null-значениями. Установить, с какими записями родительской таблицы были связаны измененные записи дочерней таблицы, после выполнения операции уже нельзя. 

Все СУБД для ПК можно подразделить на 3 вида: 

1. Системы управления БД в буквальном смысле этого термина, для которых работа с базами возможна только после запуска в работу этой системы без возможности создания автономных программ, работающих с базами. К этим системам относятся: Access, Paradox, dBase.
2. Системы, имеющие как средства для работы с БД, так и возможности разработки исполняемых в операционной системе пользовательских программ (приложений), т.е. средства разработчика программ - FoxPro.
3. Системы для разработки пользовательских программ для работы с БД - Clipper, Clarion.

Все подобные СУБД имеют в своем составе средства для: 

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

Важными факторами, определяющими выбор СУБД являются:

1. Формат БД, обеспечивающий возможность обмена информацией с другими приложениями операционной системы. Одним из самых распространенных форматов является dbf-формат, с которым работают dBase, FoxBase, FoxPro, Visual FoxPro, Clipper. Его "понимают" все приложения MS Office. Данные из этих баз можно переносить в Word, Excel, Access. Свои собственные форматы данных имеют Clarion, Paradox, Access.
2. Обеспечение секретности и конфиденциальности данных - имеют системы, не ориентированные на разработчика программ: Access, Paradox. Однако этот фактор может быть реализован при хранении данных на выделенном сервере, где права различных пользователей легко разграничить.

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

Последние версии СУБД, разработанные для работы в OC Windows 95, относятся к классу RAD-систем (Rapid Application Development) - средства быстрой разработки приложений - и имеют объектно-ориентированный язык программирования. Это такие системы, как Visual FoxPro, MS Access, Visual dBase и другие.

Постреляционные БД

В настоящее время известны также так называемые "постреляционные" СУБД, в основе которых лежат модель данных в виде многомерных таблиц и широкое использование принципов объектно-ориентированного подхода при организации БД и программировании.

Серверы БД 

В локальных и глобальных компьютерных сетях широко применяются серверы: компьютеры и программные средства для обслуживания клиентов - рабочих станций и/или других серверов

Примерами серверов могут быть:

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

Термин "сервер БД" обычно используют для обозначения всей СУБД, основанной на архитектуре "клиент-сервер", включая серверную и клиентскую части. Наиболее распространенными серверами являются в настоящее время Microsoft SQl Server, Oracle, IBM DB2 Universal DataBase, Informix и др. Размер одной БД на этих серверах может достигать миллиона терабайт.

Распределенные БД

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

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

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

Общие сведения о проектировании информационных систем и баз данных

Некоторые термины и определения, используемые при работа с базами данных

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

Предметная область - некоторая часть реально существующей системы, функционирующая как самостоятельная единица.

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

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

Таблица базы данных (table) - регулярная структура, которая состоит из однотипных строк (записей, records), разбитых на столбцы (поля, fields).

В теории реляционных баз данных синоним таблицы - отношение (relation), в котором строка называется кортежем, а столбец называется атрибутом.

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

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

Первичный ключ (primary key) главный ключевой элемент, однозначно идентифицирующий строку в таблице. Могут также существовать альтернативный (candidate key) и уникальный (unique key) ключи, служащие также для идентификации строк в таблице.

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

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

Связь (relation) - функциональная зависимость между объектами.  В реляционных БД между таблицами устанавливаются связи по ключам, один из которых в главной (parent, родительской) таблице - первичный, второй - внешний ключ- во внешней (child, дочерней) таблице, как правило. первичным не является и образует связь "один ко многим" (1:N). В случае первичного внешнего ключа связь между таблицами имеет тип "один к одному"(1:1). Информация о связях сохраняется в БД.

Внешний ключ (foreign key) - ключевой элемент подчиненной (внешней, дочерней) таблицы, значение которого совпадает со значением первичного ключа главной (родительской) таблицы.

Ссылочная целостность данных (referential integrity) - набор правил, обеспечивающих соответствие ключевых значений в связанных таблицах.

Хранимые процедуры (stored procedures) - программные модули, сохраняемые в БД для выполнения определенных операций с информацией базы.

Триггеры (triggers) - хранимые процедуры, обеспечивающие соблюдение условий ссылочной целостности определенных операций с информацией базы.

Объект - элемент информационной системы, обладающий определенными свойствами (properties) и определенным образом реагирующий на внешние события (events).

Система - совокупность взаимодействующих между собой и с внешним окружением объектов.

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

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

Язык SQL (Structured Query Language) - универсальный язык работы с БД, включающий возможности ее создания, модификации структуры, отбора данных по запросам, модификации информации в базе и прочие операции манипулирования базой данных.

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

Принципы проектирования Информационных Систем (ИС)

При создании проекта ИС для проектирования её базы данных следует определить:

1. объекты ИС (сущности в концептуальной модели)
2. их свойства (атрибуты)
3. взаимодействие объектов (связи) и информационные потоки внутри и между ними

Схема формирования ИС

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

Физическая модель - отражает все свойства (атрибуты) информационных объектов базы и связи между ними с учетом способа их хранения - используемой СУБД.

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

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

На этапах проектирования и программирования могут использоваться методы объектно-ориентированного подхода к разработке объектов ИС (наследование, инкапсуляция, полиморфизм)

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

К таким стандартам относятся методологии семейства IDEF (Icam DEFinition, ICAM - Integrated Computer-Aided Manufacturing - первоначально разработанная в конце 70-х гг. программа ВВС США интегрированной компьютерной поддержки производства). С их помощью можно эффективно проектировать, отображать и анализировать модели деятельности широкого спектра сложных систем в различных разрезах. В настоящий момент к семейству IDEF относятся следующие стандарты:

• IDEF0 - Function Modeling - методология фунционального моделирования сложных систем. С помощью наглядного графического языка IDEF0 изучаемая система предстает перед разработчиками и аналитиками в виде набора взаимосвязанных функциональных блоков. Основана на технологии SADT - структурированного анализа и разработки (Structured Analysis and Design Technique). Как правило, моделирование средствами IDEF0 является первым этапом изучения любой системы
• IDEF1 - Information Modeling - методология моделирования информационных потоков внутр и системы, позволяющая отображать и анализировать их структуру и взаимосвязи
• IDEF1X (IDEF1 Extended) - Data Modeling - методология проектирования реляционных БД. Заключается в построении моделей данных типа "сущность-связь" (ERD - Entity-Relationship Diagram) в нотации этого стандарта
• IDEF2 - Simulation Model Design - методология динамического моделирования систем. В настоящее время существуют алгоритмы и их компьютерные реализации, которые позволяют превращать набор статистических диаграмм IDEF0 в динамические модели, построенные на базе "раскрашенных сетей Петри" (CPN - Color Petri Nets)
• IDEF3 - Process Decription Capture - методология документирования процессов, происходящих в системе, которая используется. например, при исследовании технологических процессов на предприятии. С помощью IDEF3 описываются сценарий и последовательность операций для каждого процесса. IDEF3 имеет прямую взаимосвязь с методологией IDEF0 - каждая функция (функциональный блок) может быть представлена в виде отдельного процесса средствами IDEF3
• IDEF4 - Object-Oriented Capture - методология построения объектно-ориентированных систем. Средства IDEF4 позволяют наглядно отображать структуру объектов и заложенные принципы их взаимодействия, тем самым позволяя анализировать и оптимизировать сложные объектно-ориентированные системы
• IDEF5 - Ontology Description Capture - методология онтологического исследования сложных систем. В методологии IDEF5 онтология системы может быть описана при помощи определенного словаря терминов и правил, на основании которых могут быть сформированы достоверные утверждения о состоянии рассматриваемой системы в некоторый момент времени. На основе этих утверждений формируются выводы о дальнейшем развитии системы, и производится ее оптимизация
• IDEF6 - Design Rationale Capture - методология использования рационального опыта проектирования, назначение: сохранение рационального опыта проектирования информационных систем для предотвращения структурных ошибок при новом проектировании
• IDEF7 - Information System Auditing - методология аудита информационной системы
• IDEF8 - User Interface Modeling - методология проектирования интерфейса пользователя
• IDEF9 - Scenaro-Driven IS Design - методология анализа имеющихся условий и ограничений, в том числе физических, юридических, политических, и их влияние на принимаемые решения в процессе реинжиниринга 
• IDEF10 - Implementation Architechure Modeling - моделирование архитектуры выполнения
• IDEF11 - Information Artifact Modeling - информационное моделирование артефактов
• IDEF12 - Organization Modeling - организационное моделирование
• IDEF13 - Three Schema Mapping Design - трехсхемный дизайн карт
• IDEF14 - Network Design - методология моделирования компьютерных сетей. Позволяет выполнять представление и анализ данных при проектировании вычислительных сетей на графическом языке с описанием конфигураций, очередей, сетевых компонентов, требований к надежности и т.п.

Описание стандартов можно найти на сайтах:  http://www.idef.ru, http://www.idef.com;

 http://www.vpg.ru/main.mhtml?PubID=6

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

• верхняя сторона имеет значение "Управление" (Control)
• левая сторона имеет значение "Вход" (Input)
• правая сторона имеет значение "Выход" (Output)
• нижняя сторона имеет значение "Механизм" (Mechanism)

Принципы изображения функциональных моделей стандарта IDEF0 используют инструментальные средства моделирования (CASE - средства - Computer-Aided Software System Engineering), такие как BPwin.

В стандарте IDEF1 сущности и связи концептуальной модели изображаются следующим образом

Метод IDEF1, являясь методом анализа, описывает: 

• как информация собирается, хранится и обрабатывается на предприятии
• правила и логику управления информацией
• проблемы, возникающие из недостатка хорошего информационного управления

Другие методологии, используемые при моделировании сложных систем: 

• DFD-технология анализа "потока данных" (Data Flow Diagrams)
• Workflow-технология анализа "потока работ"

Важное место в моделировании информационных систем занимает методология и системы, использующие UML - унифицированный язык моделирования (Unified Modeling Language)

UML - язык для спецификации, визуализации, конструирования и документирования сложных информационно-насыщенных объектных систем. В настоящее время зарегистрирован как международный стандарт ISO/IEC 19501:2005 

UML - модель может включать следующие аспекты:

1. Структурный аспект: Use-Case-диаграммы, идентифицирующие бизнес-процессы и бизнес-транзакции, их взаимосвязь, соподчиненность и взаимодействие; Package-диаграммы, описывающие структуру предметной области и иерархическую структуру организации
2. Динамический аспект: Behavior-диаграммы (Activity, Statechart, Collaboration, Sequence), описывающие поведедение (жизненный цикл) БП и их взаимодействие во времени и в пространстве с привязкой к используемым ресурсам и получаемым результатам
3. Статический аспект: Class-диаграммы, отражающие совокупность взаимосвязанных объектов, т.е. рассматривающие логическую структуру предметной области, ее внутренние концепции, иерархию объектов и статические связи между ними, структуры данных и объектов; Deployment-диаграммы, отражающие технологические ресурсы организации

Словарь языка UML включает три вида строительных блоков: 

• сущности
• отношения
• диаграммы

Сущности  в UML - это абстракции, являющиеся основными элементами модели. Отношения связывают различные сущности; диаграммы группируют представляющие интерес совокупности сущностей.

В UML имеется четыре типа сущностей:

• структурные
• поведенческие
• группирующие
• аннотационные

Структурные сущности - это имена существительные в моделях на языке UML. Как правило, они представляют собой статические части модели, соответствующие концептуальным или физическим элементам системы. Существует семь разновидностей структурных сущностей: Класс, Интерфейс, Кооперация, Прецедент, Активный класс, Компонент, Узел.

Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы языка: они описывают поведение модели во времени и пространстве. Существует всего два основных типа поведенческих сущностей: Взаимодействие и Автомат.

Группирующие сущности являются организующими частями модели UML. Это блоки, на которые можно разложить модель. Есть только одна первичная группирующая сущность, а именно - пакет.

Аннотационные сущности - пояснительные части модели UML. Это комментарии для дополнительного описания, разъяснения или значения к любому элементу модели. Имеется только один базовый тип аннотационных элементов - примечание. 

Все разновидности сущностей UML в диаграммах имеют свой способ графического изображения.

В языке UML определены четыре типа отношений:

• зависимость
• ассоциация
• обобщение
• реализация

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

• диаграммы классов (Class Diagrams)
• диаграммы объектов (Objects Diagrams)
• диаграммы прецедентов (Use Cases Diagrams)
• диаграммы последовательностей (Sequence Diagrams)
• диаграммы кооперации(Collaboration Diagrams)
• диаграммы состояния (State Diagrams)
• диаграммы действий (Activity Diagrams)
• диаграммы компонентов (component Diagrams)
• диаграммы развертывания (Deployment Diagrams)

Инструментальные средства, поддерживающие методологию UML - Rational Rose (Rational Software), Paradigm Plus (CA/Platinum), ARIS (IDS Sheer AG), Together Designer (Borland) и др.

Система Rational Rose позволяет строить восемь типов диаграмм UML; диаграммы прецедентов, диаграммы классов, диаграммы последовательностей, диаграммы кооперации, диаграммы состояний, диаграммы действий, компонентные диаграммы, диаграммы развертывания. Основным типом диаграмм, своеобразным ядром моделирования в UML являются диаграммы классов. Кроме UML, предусмотрено использование и других методов (Booch, OMT)

Система Paradigm Plus ориентирована на методологию OOCL (Object Oriented Change and Learning) и компонентную технологию проектирования и разработки. Она поддерживает диаграммы различных методов (UML, CLIPP, TeamFusion, OMT, Booch, OOCL, Martin/Odell, Shlaer/Mellor, Coad/yourdon)

Система ARIS обеспечивает четыре различных "взгляда" на моделирование и анализ: Процессы, Функции (с целями), Данные, Организация. Для каждого "взгляда" поддерживаются три уровня анализа (требования, спецификация, внедрение). Каждый из уровней анализа состоит из своего комплекта моделей различных типов, в том числе диаграмм UML, диаграмм SAP/R3 и др. Каждый объект моделей ARIS имеет множество атрибутов, которые позволяют контролировать процесс разработки моделей, определять условия для выполнения функционально-стоимостного анализа, имитационного моделирования, взаимодействия с workflow-системами и т.д.

Система Together Designer Community Edition - средство создания диаграмм UML 2.0. Позволяет строить диаграммы прецедентов (диаграммы сценариев взаимодействия пользователя с продуктом с точки зрения пользователя); диаграммы последовательностей, описывающие порядок передачи сообщений от одних объектов к другим; диаграммы кооперации, описывающие взаимодействие объектов друг с другом; диаграммы деятельности, описывающие потоки работ и изменение состояний объектов, диаграммы развертывания. При необходимости может создаваться логическая модель данных, содержащая диаграммы "сущность-связь", на ее основе генерируется физическая модель данных для конкретной СУБД, выбранной для реализации проекта.

На этапе создания клиентского и серверного кода все современные средства UML-моделирования могут осуществлять генерацию кода на различных языках программирования.

В феврале 2006 г. международный консорциум по разработке спецификаций в компьютерной индустрии опубликовал финальную версию языка моделирования БП BPML (Business Process Modeling Language) 

Для проектирования концептуальной модели и формирования физической модели БД информационной системы можно использовать инструментальные CASE-средства (Computer-Aided Software System Engineering), например, Case Studio, SyBase Power Designer, ERWin Data Modeler и др. Данные системы применяются при описании модели данных стандарт IDEF1X и позволяют генерировать программный код на языках SQL, VBScript, JScript, либо работать с другими технологиями для переноса физической модели в реальные СУБД, которыми могут быть Oracle, Microsoft SQL Server, IBM DB2, Informix, Microsoft Access.

На рисунке приведена схема, показывающая взаимосвязь основных терминов в области проектирования БД и работы с ними.

Выбор системы для разработки приложений, работающих с БД, сложное и ответственное решение. Такую возможность имеют универсальные системы программирования: Visual C++ и C#, Delphi, Visual Basic и др. Однако специализированные языки программирования в составе СУБД располагают огромным количеством процедур и функций для работы с БД, специальными библиотеками, механизмами для ускорения работы с большими БД.  В связи  с повсеместным распространением Интранета, Экстранета, и Интернета, многие системы имеют возможность создания трехуровневой сервис-ориентированной архитектуры WEB- приложений для работы с БД,