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

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

3. служащие или начальник почтового отделения могут:

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

    Пользователям, работающим с данной базой данных, необходимы следующие отчеты:

1. отчет по известным печатным изданиям, содержащий следующие данные:

• шифр, название, ФИО редактора этого издания;

• тираж и цена этого издания в различных типографиях;

2. отчет о работе типографий, содержащий следующие данные:

• номер, адрес и ФИО директора типографии;
• шифры, названия, тиражи и цены выпускаемых изданий;
• адреса рассылки (номера и адреса почтовых отделений) для каждого печатного издания;
• объем заказа и цену доставки для каждого почтового отделения;

3. отчет о работе почтовых отделений, содержащий следующие данные:

• номер, адрес и ФИО начальника почтового отделения;
• шифр, название, объем заказа и цена доставки покупаемых изданий;
• номера и адреса типографий, в которых заказаны издания.

4. отчет о работе определенного почтового отделения, содержащий следующие данные:

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

 
 
 
 
 
 
 
 

2. ПРОЕКТИРОВАНИЕ БАЗЫ  ДАННЫХ 

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

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

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

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

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

2.1. Методология проектирования 

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

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

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

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

Временные характеристики и транзакции. 

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

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

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

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

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

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

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

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

2.1.1. Метод нормальных  форм

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

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

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

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

    Атрибут В функционально зависит о атрибута А, если каждому значению А соответствует в точности одно значение В (обозначение: А®В). Функциональная взаимозависимость атрибутов А и В означает, что имеется взаимнооднозначное соответствие, т.е. А®В и В®А (А«В). Функциональная частичная зависимость – зависимость неключевого атрибута от части составного ключа. Полная функциональная зависимость – зависимость неключевого атрибута от всего составного ключа.

    Атрибут С зависит от атрибута А транзитивно, если для атрибутов А,В,С выполняется условие А®В и В®С, но обратная зависимость отсутствует.

    Атрибут В многозначно зависит от атрибута А, если каждому значению А соответствует множество значений В, не связанных с другими атрибутами. Эти зависимости могут быть «один ко многим», «многие к одному» или «многие ко многим» (1:m, m:1, m:m соответственно), обозначаемые соответственно АÞВ, ВÞА и АÛВ.