Установить ssl соединение. Как установить SSL сертификат. Какие подводные камни вас ждут. Делюсь своим опытом. становка на хостинг.masterhost

Федеральное агентство по образованию

Государственное образовательное учреждение высшего профессионального образования

АМУРСКИЙ ГОСУДАРСТВЕННЫЙ УНИВЕРСИТЕТ

(ГОУВПО «АмГУ»)

КОНТРОЛЬНАЯ РАБОТА

по дисциплине «Информационные системы в экономике»

на тему: «Принципы построения и этапы проектирования баз данных»

Исполнитель

студент группы С – 81 Н.А. Вохмянина

Руководитель

доцент, к. т. н. Д. Г. Шевко

Благовещенск 2010

Введение

1. Принципы построения баз данных

2. Концепции построения баз данных

3. Этапы проектирования баз данных

Библиографический список

ВВЕДЕНИЕ

Восприятие реального мира можно соотнести с последовательностью разных, хотя иногда и взаимосвязанных, явлений. С давних времен люди пытались описать эти явления (даже тогда, когда не могли их понять). Такое описание называют данными.

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

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

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

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

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

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

1. ПРИНЦИПЫ ПОСТРОЕНИЯ БАЗ ДАННЫХ

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

1. Высокое быстродействие (малое время отклика на запрос).

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

2. Простота обновления данных.

3. Независимость данных.

4. Совместное использование данных многими пользователями.

5. Безопасность данных - защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.

6. Стандартизация построения и эксплуатации БД (фактически СУБД).

8. Дружелюбный интерфейс пользователя.

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

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

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

Безопасность данных включает их целостность и защиту.

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

Она предполагает:

1. отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;

2. защиту от ошибок при обновлении БД;

3. невозможность удаления (или каскадное удаление) связанных данных разных таблиц;

4. неискажение данных при работе в многопользовательском режиме и в распределенных базах данных;

5. сохранность данных при сбоях техники (восстановление данных).

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

1. введением системы паролей;

2. получением разрешений от администратора базы данных (АБД);

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

Три последние процедуры легко выполняются в рамках языка структуризованных запросов Structured Query Language - SQL, часто называемого SQL2.

Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).

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

Существует два подхода к построению БД, базирующихся на двух подходах к созданию автоматизированной системы управления (АСУ).

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

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

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

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

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

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

Проектирование баз данных происходит в четыре этапа.

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

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

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

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

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

Руководство по проектированию баз данных.

1. Вступление.

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

Реляционная модель.

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

Примеры.

РСУБД.

РСУБД, которую я использовал для создания таблиц примеров – MySQL. MySQL – наиболее популярная РСУБД и она бесплатна.

Утилита для администрирования БД.

После установки MySQL вы получаете только интерфейс командной строки для взаимодействия с MySQL. Лично я предпочитаю графический интерфейс для управления моими базами данных. Я часто использую SQLyog. Это бесплатная утилита с графическим интерфейсом. Изображения таблиц в данном руководстве взяты оттуда.

Визуальное моделирование.

Существует отличное бесплатное приложение MySQL Workbench. Оно позволяет спроектировать вашу базу данных графически. Изображения диаграмм в руководстве сделаны в этой программе.

Проектирование независимо от РСУБД.

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

2. История.

Так выглядели профессионалы в сфере информационных технологий в 70-е. (Слева внизу находится Билл Гейтс).

Текстовые файлы и сегодня все еще используются для хранения малых объемов простой информации. Comma-Separated Values (CSV) - значения, разделённые запятыми, очень популярны и широко поддерживаются сегодня различным программным обеспечением и операционными системами. Microsoft Excel – один из примеров программ, которые могут работать с CSV–файлами. Данные, сохраненные в таком файле могут быть считаны компьютерной программой.

Выше приведен пример того, как такой файл мог бы выглядеть. Программа, производящая чтение данного файла, должна быть уведомлена о том, что данные разделены запятыми. Если программа хочет выбрать и вывести категорию, в которой находится урок "Database Design Tutorial" , то она должна строчка за строчкой производить чтение до тех пор, пока не будут найдены слова "Database Design Tutorial" и затем ей нужно будет прочитать следующее за запятой слово для того, чтобы вывести категорию Software .

Таблицы баз данных.

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

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

История реляционной модели.

Сегодня доступен широкий выбор систем управления базами данных: от небольших десктопных приложений до многофункциональных серверных систем с высокооптимизированными методами поиска. Вот некоторые из наиболее известных систем управления реляционными базами данных (РСУБД):

- Oracle – используется преимущественно для профессиональных, больших приложений.
- Microsoft SQL server – РСУБД компании Microsoft. Доступна только для операционной системы Windows.
- Mysql – очень популярная РСУБД с открытым исходным кодом. Широко используется как профессионалами, так и новичками. Что еще нужно?! Она бесплатна.
- IBM – имеет ряд РСУБД, наиболее известна DB2.
- Microsoft Access – РСУБД, которая используется в офисе и дома. На самом деле – это больше, чем просто база данных. MS Access позволяет создавать базы данных с пользовательским интерфейсом.
В следующей части я расскажу кое-что о характеристиках реляционных баз данных.

3. Характеристики реляционных баз данных.

Использование ключей.

Используя структурированный язык запросов (SQL), данные из разных таблиц, которые связаны ключом, могут быть выбраны за один раз. Для примера вы можете создать запрос, который выберет все заказы из таблицы заказов (orders), которые принадлежат пользователю с идентификатором (id) 3 (Mike) из таблицы пользователей (users). О ключах мы поговорим далее, в следующих частях.

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

Отсутствие избыточности данных.

Ограничение ввода.

Когда вы создаете таблицу базы данных вы предоставляете тип данных для каждого столбца. К примеру, varchar – это тип данных для небольших фрагментов текста с максимальным количеством знаков, равным 255, а int – это числа.

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

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

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

Поддержание целостности данных.

Назначение прав.

Структурированный язык запросов (SQL).

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

Переносимость.

Как говорилось ранее, проектирование базы данных – это вопрос идентификации данных, их связи и помещение результатов решения данного вопроса на бумагу (или в компьютерную программу). Проектирование базы данных независимо от РСУБД, которую вы собираетесь использовать для ее создания.

В следующей части подробнее рассмотрим первичные ключи.

Темы: этапы проектирования баз данных, проектирование базы данных на основе модели типа объект — отношение.

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

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

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

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

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

Построение информационно-логической модели данных предметной области;

Определение логической структуры реляционной базы данных;

Конструирование таблиц базы данных;

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

Ввод данных в таблицы (создание записей);

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

Разработка пользовательского интерфейса.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Проектирование базы данных на основе модели типа объект — отношение

Имеется целый ряд методик создания информационно-логических моделей. Одна из наиболее популярных в настоящее время методик при разработке моделей использует ERD (Entity-Relationship Diagrams). В русскоязычной литературе эти диаграммы называют «объект — отношение» либо «сущность — связь». Модель ERD была предложена Питером Пин Шен Ченом в 1976 г. К настоящему времени разработано несколько ее разновидностей, но все они базируются на графических диаграммах, предложенных Ченом. Диаграммы конструируются из небольшого числа компонентов. Благодаря наглядности представления они широко используются в CASE-средствах (Computer Aided Software Engineering).

Рассмотрим используемую терминологию и обозначения.

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

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

Каждая сущность должна обладать некоторыми свойствами:

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

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

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

Сущность может быть независимой либо зависимой. Признаком зависимой сущности служит наличие у нее наследуемых через связь атрибутов (рис. 1.).

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

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

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

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

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

Продавец может получить вознаграждение за один или более Контрактов;

Контракт должен быть инициирован ровно одним Продавцом.

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

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

Экземпляр атрибута — это определенная характеристика конкретного экземпляра сущности. Экземпляр атрибута определяется типом характеристики (например, «Цвет») и ее значением (например, «лиловый»), называемым значением атрибута. В ER-модели атрибуты ассоциируются с конкретными сущностями. Каждый экземпляр сущности должен обладать одним конкретным значением для каждого своего атрибута.

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

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

Характер идентификации отображается в диаграмме на линии связи (рис. 4).

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

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

В настоящее время на основе подхода Чена создана методология IDEF1X , которая разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEFlX-диаграммы используются рядом распространенных CASE-средств (в частности, ERwin, Design/IDEF).

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

Каждой сущности присваивается уникальное имя и номер, разделяемые косой чертой «/» и помещаемые над блоком.

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

Идентифицирующая связь между сущностью-родителем и сущностью-потомком изображается сплошной линией. На рис. 5: №2 — зависимая сущность, Связь 1 — идентифицирующая связь. Сущность-потомок в идентифицирующей связи является зависимой от идентификатора сущностью. Сущность-родитель в идентифицирующей связи может быть как независимой, так и зависимой от идентификатора сущностью (это определяется ее связями с другими сущностями).

Штриховая линия изображает неидентифицирующую связь. На рис. 5: №4 — независимая сущность, Связь 2 — неидентифицирующая связь. Сущность-потомок в неидентифицируюшей связи будет независимой от идентификатора, если она не является также сущностью-потомком в какой-либо идентифицирующей связи.

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

В IDEF1X могут быть выражены следующие мощности связей:

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

Каждый экземпляр сущности-родителя должен иметь не менее одного связанного с ним экземпляра сущности-потомка;

Каждый экземпляр сущности-родителя должен иметь не более одного связанного с ним экземпляра сущности-потомка;

Каждый экземпляр сущности-родителя связан с некоторым фиксированным числом экземпляров сущности-потомка.

Мощность связи обозначается, как показано на рис. 6 (мощность по умолчанию — N).

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

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

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

Этапы проектирования базы данных

Процесс проектирования включает в себя следующие этапы:

• 1. Инфологическое проектирование.
• 2. Определение требований к операционной обстановке, в которой будет функционировать информационная система.
• 3. Выбор системы управления базой данных (СУБД) и других инструментальных программных средств.
• 4. Даталогическое(логическое) проектирование БД.
• 5. Физическое проектирование БД.

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

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

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

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

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

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

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

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

Примеры.

Объект "Человек " обладает свойствами: рост, имя, дата рождения … ,

объект - "Изделие " обладает свойствами: качество, дата изготовления, внешний вид….

Между объектами существуют многочисленные связи. Например:

• · Человек покупает, продает, производит Изделие
• · Изделие создается, покупается, продается Человеком .

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

Все действия по выявлению ядра предметной области производятся на этапе анализа ИС.

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

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

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

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

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

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

Основные понятия ER-диаграмм. Основными понятиями ER-модели являются сущность, связь и атрибут.

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

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

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

Примерами сущностей могут быть такие классы объектов как "Поставщик", "Сотрудник", "Накладная".

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

Определение 2 . Экземпляр сущности - это конкретный представитель данной сущности.

Например, представителем сущности "Сотрудник" может быть "Сотрудник Иванов".

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

Определение 3 . Атрибут сущности - это поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, КРАСКА и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д.

Здесь также существует различие между типом атрибута и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута.

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

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

Примерами атрибутов сущности "Сотрудник" могут быть такие атрибуты как "Табельный номер", "Фамилия", "Имя", "Отчество", "Должность", "Зарплата" и т.п.

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

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

Описательные атрибуты представляют факты, внутренне присущие каждому экземпляру сущности.

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

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

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

Например, для сущности Расписание ключом является атрибут Номер_рейса или набор: Пункт_отправления , Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет).

Сущность может иметь несколько различных ключей.

Ключевые атрибуты изображаются на диаграмме подчеркиванием:

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

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

Например, связи между сущностями могут выражаться следующими фразами - "СОТРУДНИК может иметь несколько ДЕТЕЙ", "каждый СОТРУДНИК обязан числиться ровно в одном ОТДЕЛЕ".

Графически связь изображается линией, соединяющей две сущности:

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

Каждая связь может иметь один из следующих типов связи :

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

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

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

Каждая связь может иметь одну из двух модальностей связи :

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

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

Связь может иметь разную модальность с разных концов.

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

<Каждый экземпляр СУЩНОСТИ 1> <МОДАЛЬНОСТЬ СВЯЗИ> <НАИМЕНОВАНИЕ СВЯЗИ> <ТИП СВЯЗИ> <экземпляр СУЩНОСТИ 2>.

Каждая связь может быть прочитана как слева направо, так и справа налево. Например, связь, представленная на рисунке выше 4 читается так:

Слева направо: "каждый сотрудник может иметь несколько детей".

Справа налево: "Каждый ребенок обязан принадлежать ровно одному сотруднику".

Нормальные формы ER-схем. Как и в реляционных схемах баз данных, в ER-диаграмах вводится понятие нормальных форм, причем их смысл очень близко соответствует смыслу реляционных нормальных форм. Приведем только очень краткие и неформальные определения трех первых нормальных форм.

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

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

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

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

Получение реляционной схемы из ER-схемы:

Шаг 1. Каждая простая сущность превращается в таблицу. Простая сущность - сущность, не являющаяся подтипом и не имеющая подтипов. Имя сущности становится именем таблицы.

Шаг 2. Каждый атрибут становится возможным столбцом с тем же именем; может выбираться более точный формат. Столбцы, соответствующие необязательным атрибутам, могут содержать неопределенные значения; столбцы, соответствующие обязательным атрибутам, - не могут.

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

Шаг 4. Связи многие-к-одному (и один-к-одному) становятся внешними ключами. Т.е. делается копия уникального идентификатора с конца связи "один", и соответствующие столбцы составляют внешний ключ. Необязательные связи соответствуют столбцам, допускающим неопределенные значения; обязательные связи - столбцам, не допускающим неопределенные значения.

Шаг 5. Индексы создаются для первичного ключа (уникальный индекс), внешних ключей и тех атрибутов, на которых предполагается в основном базировать запросы.

Шаг 6. Если в концептуальной схеме присутствовали подтипы, то возможны два способа:

• · все подтипы в одной таблице (а)
• · для каждого подтипа - отдельная таблица (б)

При применении способа (а) таблица создается для наиболее внешнего супертипа, а для подтипов могут создаваться представления. В таблицу добавляется по крайней мере один столбец, содержащий код ТИПА; он становится частью первичного ключа.

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

Шаг 7. Имеется два способа работы при наличии исключающих связей:

• · общий домен (а)
• · явные внешние ключи (б)

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

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

Пример разработки простой ER-модели. При разработке ER-моделей мы должны получить следующую информацию о предметной области:

• 1. Список сущностей предметной области.
• 2. Список атрибутов сущностей.
• 3. Описание взаимосвязей между сущностями.

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

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

Например, в ходе беседы с менеджером по продажам, выяснилось, что он (менеджер) считает, что проектируемая система должна выполнять следующие действия:

• · Хранить информацию о покупателях.
• · Печатать накладные на отпущенные товары.
• · Следить за наличием товаров на складе.

Выделим все существительные в этих предложениях - это будут потенциальные кандидаты на сущности и атрибуты, и проанализируем их (непонятные термины будем выделять знаком вопроса):

• · Покупатель
• · Накладная - явный кандидат на сущность.
• · Товар - явный кандидат на сущность
• · (?)Склад - а вообще, сколько складов имеет фирма? Если несколько, то это будет кандидатом на новую сущность.
• · (?)Наличие товара - это, скорее всего, атрибут, но атрибут какой сущности?

Сразу возникает очевидная связь между сущностями - "покупатели могут покупать много товаров" и "товары могут продаваться многим покупателям". Первый вариант диаграммы выглядит так:

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

Куда поместить сущности "Накладная" и "Склад" и с чем их связать? Спросим себя, как связаны эти сущности между собой и с сущностями "Покупатель" и "Товар"?

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

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

инфологический атрибут информационный отображение

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

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

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

• · Юридическое лицо - термин риторический, мы не работаем с физическими лицами. Не обращаем внимания.
• · Наименование покупателя
• · Адрес - явная характеристика покупателя.
• · Банковские реквизиты - явная характеристика покупателя.
• · Наименование товара
• · (?)Цена товара - похоже, что это характеристика товара. Отличается ли эта характеристика от цены в накладной?
• · Единица измерения - явная характеристика товара.
• · Номер накладной - явная уникальная характеристика накладной.
• · Дата накладной - явная характеристика накладной.
• · (?)Список товаров в накладной - список не может быть атрибутом. Вероятно, нужно выделить этот список в отдельную сущность.
• · (?)Количество товара в накладной - это явная характеристика, но характеристика чего? Это характеристика не просто "товара", а "товара в накладной".
• · (?)Цена товара в накладной - опять же это должна быть не просто характеристика товара, а характеристика товара в накладной. Но цена товара уже встречалась выше - это одно и то же?
• · Сумма накладной - явная характеристика накладной. Эта характеристика не является независимой. Сумма накладной равна сумме стоимостей всех товаров, входящих в накладную.
• · Наименование склада - явная характеристика склада.

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

С возникающим понятием "Список товаров в накладной" все довольно ясно.

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

Этой сущностью и будет сущность "Список товаров в накладной". Связь ее с сущностями "Накладная" и "Товар" характеризуется следующими фразами

- "каждая накладная обязана иметь несколько записей из списка товаров в накладной",

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

Атрибуты "Количество товара в накладной" и "Цена товара в накладной" являются атрибутами сущности " Список товаров в накладной".

Точно также поступим со связью, соединяющей сущности "Склад" и "Товар". Введем дополнительную сущность "Товар на складе". Атрибутом этой сущности будет "Количество товара на складе". Таким образом, товар будет числиться на любом складе и количество его на каждом складе будет свое.

Теперь можно внести все это в диаграмму:

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

На данной диаграмме каждая сущность представляет собой таблицу базы данных, каждый атрибут становится колонкой соответствующей таблицы. Обращаем внимание на то, что во многих таблицах, например, "CUST_DETAIL" и "PROD_IN_SKLAD", соответствующих сущностям "Запись списка накладной" и "Товар на складе", появились новые атрибуты, которых не было в концептуальной модели - это ключевые атрибуты родительских таблиц, мигрировавших в дочерние таблицы для того, чтобы обеспечить связь между таблицами посредством внешних ключей.

Полученные таблицы находятся в 3НФ.

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

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

Более сложные элементы ER-модели. Мы остановились только на самых основных и наиболее очевидных понятиях ER-модели данных. К числу более сложных элементов модели относятся следующие:

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

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

Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, т.е. любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты приходится определять дополнительный подтип ПРОЧИЕ.

Пример: Супертип ЛЕТАТЕЛЬНЫЙ АППАРАТ

Как полагается это читать? От супертипа: ЛЕТАТЕЛЬНЫЙ АППАРАТ, который должен быть АЭРОПЛАНОМ, ВЕРТОЛЕТОМ, ПТИЦЕЛЕТОМ или ДРУГИМ ЛЕТАТЕЛЬНЫМ АППАРАТОМ. От подтипа: ВЕРТОЛЕТ, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА. От подтипа, который является одновременно супертипа: АЭРОПЛАН, который относится к типу ЛЕТАТЕЛЬНОГО АППАРАТА и должен быть ПЛАНЕРОМ или МОТОРНЫМ САМОЛЕТОМ.

Иногда удобно иметь два или более разных разбиения сущности на подтипы. Например, сущность ЧЕЛОВЕК может быть разбита на подтипы по профессиональному признаку (ПРОГРАММИСТ, ДОЯРКА и т.д.), а может - по половому признаку (МУЖЧИНА, ЖЕНЩИНА).

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

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

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

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

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

· проектирование;

· программная реализация;

· заполнение и эксплуатация.

Этап проектирования – это теоретическое построение исходной информационной модели базы данных. Он включает в себя:

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

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

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

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

· определение логической структуры базы данных;

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

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

· описать полученные таблицы средствами СУБД и ввести их в компьютер;

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

· выработать порядок ведения и поддержания базы данных в рабочем состоянии, работы конечных пользователей;

· провести тестирование системы, составить инструкции по работе с ней и обучить персонал.

Этап эксплуатации и заполнения начинается с наполнения базы данных конкретными данными. Он включает в себя непосредственное ведение базы данных и её сопровождение.

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

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

Концептуальное проектирование базы данных

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

Логическое проектирование базы данных

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

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

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

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

Нормализация базы данных

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

Рассмотрим пример нормализации БД управления доставкой заказов. Неупорядоченная БД «Продажи» состояла бы из одной таблицы (рис.7).

Рис.7. БД «Продажи»

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

Первая нормальная форма

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

Выполним нормализацию БД " Продажи" до первой нормальной формы (рис.8).

Рис.8. Первая нормальная форма

3.3.2. Вторая нормальная форма

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

Выполним нормализацию БД " Продажи" до второй нормальной формы. Все сведения, не связанные с отдельными заказами, выделим в отдельную таблицу. В итоге получим вместо одной таблицы " Продажи" получим две - таблицу "Заказы" (рис.9) и таблицу "Товары" (рис.10).

Рис.9. Таблица "Заказы"

Рис.10. Таблица "Товары"

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

3.3.3. Третья нормальная форма

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

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

Рис. 11. Нормализованная БД "Продажи"

3.2 Программная реализация базы данных

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

Прикладные программы реализуются с помощью языков третьего или четвертого поколения. Некоторые элементы этих прикладных программ будут представлять собой транзакции обработки базы данных, записываемые на языке манипулирования данными (DML) целевой СУБД и вызываемые из программ на базовом языке программирования - например, на Visual Basic, С++, Java. Кроме того, на этом этапе создаются другие компоненты проекта приложения - например, экраны меню, формы ввода данных и отчеты. Следует учитывать, что многие существующие СУБД имеют свои собственные инструменты разработки, позволяющие быстро создавать приложения с помощью непроцедурных языков запросов, разнообразных генераторов отчетов, генераторов форм, генераторов графических изображений и генераторов приложений.

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

3.2.1. Разработка приложений

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

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

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

3.2.2 Тестирование базы данных

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

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

3.3 Эксплуатация и сопровождение базы данных

Эксплуатация и сопровождение - поддержка нормального функционирования БД.

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

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

· сопровождение и модернизация (в случае необходимости) приложений баз данных. Новые требования включаются в приложение базы данных при повторном выполнении предыдущих этапов жизненного цикла.

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

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

4. СУБД Microsoft Access

4.1.Назначение и общие сведения о СУБД Microsoft Access

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

К областям применения Microsoft Access можно отнести следующие:

· в малом бизнесе (бухгалтерский учет, ввод заказов, ведение информации о клиентах, ведение информации о деловых контактах);

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

· в качестве персональной СУБД (справочник по адресам, ведение инвестиционного портфеля, поваренная книга, каталоги книг, пластинок, видеофильмов и т. п.).

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

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

В Access реализовано управление реляционными базами данных. Система поддерживает первичные и внешние ключи. Обеспечивает целостность данных на уровне ядра, что не разрешает несовместимые операции обновления или удаления данных. Таблицы в Access снабжены средствами проверки допустимости данных, т.е. не разрешается некорректный ввод. Каждое поле таблицы имеет свой формат и стандартные описания, что облегчает ввод данных. Access поддерживает следующие типы полей, в том числе: вкладка, текстовый, числовой, счетчик, денежный, дата/время, MEMO, логический, гиперссылка, поля объектов OLE, вложение и вычисляемый. Если в полях не оказывается никаких значений, система обеспечивает полную поддержку пустых значений.

В Access можно использовать графические средства, как и в Microsoft Word, Excel, PowerPoint и других приложениях, позволяющие создавать различные виды графиков и диаграмм. Можно создавать гистограммы, двухмерные и трехмерные диаграммы. В формы и отчеты Access можно добавлять всевозможные объекты: рисунки, диаграммы, аудио- и видеоклипы. Связывая эти объекты с разработанной базой данных, можно создавать динамические формы и отчеты. Также в Access можно использовать макросы, позволяющие автоматизировать выполнение некоторых задач. Они позволяют открывать и закрывать формы и отчеты, создавать меню и диалоговые окна с целью автоматизации создания различных прикладных задач.

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

4.2. Объекты Microsoft Access

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

Рис. 12. Запуск Access

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

При создании новой базы данных Access откроет пустую таблицу, содержащую одну строку и два столбца (рис 13).

Рис.13. Окно новой базы данных

В левой части окна (область переходов) показаны все созданные объекты БД, пока мы лишь видим, пустую таблицу, т.к. созданных объектов в новой базе данных больше нет (рис. 13). К основным объектам СУБД Access относятся следующие.

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

Таблицы в Access могут быть созданы следующим образом:

· в режиме «конструктора»;

· в режиме ввода данных в таблицу.

Создать таблицу можно путем импорта данных, хранящихся в другом месте, или создания связи с ними. Это можно сделать, например, с данными, хранящимися в файле Excel, в списке Windows SharePoint Services, XML-файле, другой базе данных MS ACCESS. Список SharePoint позволяет предоставить доступ к данным пользователям, у которых не установлено приложение MS ACCESS. При импорте данных создается их копия в новой таблице текущей базы данных. Последующие изменения, вносимые в исходные данные, не будут влиять на импортированные данные, и наоборот. Если осуществляется связывание с данными, в текущей базе данных создается связанная таблица, обеспечивающая динамическое подключение к данным, хранящимся в другом месте. Изменения данных в связанной таблице отражаются в источнике, а изменения в источнике - в связанной таблице.

В режиме таблицы отображаются данные, которые хранятся в таблице, а в режиме «конструктора» отображается структура таблицы.

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

Запросы . Запросы - это специальные средства, предназначенные для поиска и анализа информации в таблицах базы данных, отвечающей определенным критериям. Найденные записи, называемые результатами запроса, можно просматривать, редактировать и анализировать различными способами. Кроме того, результаты запроса могут использоваться в качестве основы для создания других объектов Access. Существуют различные типы запросов, наиболее распространенными из которых являются запросы на выборку, параметрические и перекрестные запросы, запросы на удаление записи, изменение и другие. Реже используются запросы на действие и запросы SQL (Structured Query Language). Если нужного запроса нет, то его можно создать дополнительно.

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

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

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

· «форма»;

· «разделенная форма»;

· «несколько элементов»;

· «пустая форма».

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

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

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

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

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

Страницы. Чтобы предоставить пользователям Интернета доступ к информации, в базе данных можно создать специальные страницы доступа к данным. С помощью страниц доступа к данным можно просматривать, добавлять, изменять и обрабатывать данные, хранящиеся в базе данных. Страницы доступа к данным могут также содержать данные из других источников, например, из Excel. Для публикации информации из базы данных в Web Access включают «мастер», который обеспечивает создание страницы доступа.

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

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