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

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

База данных
(БД) – совокупность специально организованных и логически упорядоченных данных.

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

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

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

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

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

• иерархическую;
• сетевую;
• реляционную.

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

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

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

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

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

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

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

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

Прежде всего рассмотрим три главных элемента пользовательского интерфейса MS Access 2010 (МА 2010).

• Лента
  . Область вверху окна приложения, которая содержит группы команд.
• . Перечень команд на вкладке Файл, которая помещается на ленте.
• . Область в левой части окна МА 2010, созданная для работы с объектами базы данных. Область навигации заменила собой окно базы данных в Access 2007.

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

Лента
полностью заменила собой меню и панели инструментов, которые использовались в более ранних версиях МА. Она содержит вкладки с группами кнопок. Лента включает вкладки “по умолчанию” с группами наиболее типичных команд, контекстные вкладки, появляющиеся тогда, когда их использование допустимо, и панель быстрого доступа – специфическую панель инструментов, которая предназначена для добавления самых нужных команд.

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

Режим Backstage
является новинкой, созданной в МА 2010. Этот режим включает команды и сведения, которые можно применить ко всей базе данных, например Сжать
и восстановить,
и команды, которые в более ранних версиях МА находились в меню Файл,
например Печать.

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

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

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

Рис. 3.24.

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

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

• 1. Активировать МА при помощи меню Пуск
  
• 2. Запустить одну из приведенных ниже процедур.
• а) Создание веб-базы данных:
  • – в группе Доступные шаблоны
    выбрать пункт Пустая веб-база данных;
    
  • – справа в разделе Пустая веб-база данных
    в поле Имя файла
    
  • – щелкнуть кнопку Создать.
    

• б) Создание базы данных на компьютере:
  • – в группе Доступные шаблоны
    нажать пункт Пустая база данных;
    
  • – справа в разделе Пустая база данных
    в поле Имя файла
    набрать наименование файла базы данных или воспользоваться наименованием по умолчанию;
  • – нажать кнопку Создать.
    

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

МЛ 2010 включает перечень шаблонов, к тому же существует возможность загрузки дополнительных шаблонов с веб-сайта Office.com. Шаблон МА является готовой базой данных с таблицами, разработанными на профессиональном уровне, а также содержащей формы и отчеты. Шаблоны дают возможность сократить время прохождения начальных этапов создания базы данных.

Создание базы данных из образца шаблона.
Для осуществления этого необходимо сделать следующее.

• Пуск
  или воспользовавшись ярлыком. Запустится представление Backstage.
• 2. Нажать пункт Образец шаблона
  и просмотреть перечень доступных шаблонов.
• 3. Выбрать нужный шаблон.
• 4. Справа в окне “Имя файла” набрать наименование файла или воспользоваться наименованием по умолчанию.
• 5. Щелкнуть кнопку Создать.
  

Приложение МА 2010 на основе выбранного шаблона создаст новую базу данных и откроет ее.

Существует возможность загрузить дополнительные шаблоны МА 2010 с веб-сайта Office.com через представление Backstage.

Создание базы данных из шаблона Office.com.

• 1. Активировать МА 2010 при помощи меню Пуск
  или с использованием ярлыка. Запустится представление Backstage.
• 2. На панели Шаблоны Office.com
  отметить категорию и необходимый шаблон. Нужный шаблон можно найти также с помощью окна поиска.
• 3. В поле Имя файла
  набрать наименование файла или использовать наименование по умолчанию.
• 4. Щелкнуть кнопку Загрузить.
  

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

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

• 1. Активировать МА 2010.
• 2. В представлении Backstage нажать пункт Недавние
  и выбрать базу данных, которую требуется открыть. Приложение МА откроет базу данных.

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

• 1. Активировать М А 2010.
• 2. На вкладке Файл
  щелкнуть кнопку Открыть.
  В диалоговом окне Открытие
  отметить файл и щелкнуть кнопку Открыть.
  Откроется база данных.

Лента
по сути является заменой таких элементов интерфейса, как меню и панели инструментов. Лента представляет собой главный командный интерфейс МА 2010. Одно из основных преимуществ ленты – это собранные на ней средства выполнения задач, ранее содержащиеся в меню, на панелях инструментов, в областях задач и других элементах пользовательского интерфейса. Теперь требуемую команду не нужно искать в нескольких разных местах.

Когда база данных открывается, лента отображается вверху главного окна МА 2010. В этот момент она включает команды активной вкладки команд (рис. 3.25).

Рис. 3.25.

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

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

Работа с лентой может быть удобна при использовании некоторых комбинаций клавиш. При этом все комбинации клавиш из предшествующей версии МА действуют по-прежнему. Однако вместо клавиш активации меню, которые применялись в предыдущих версиях МА, действует система доступа к элементам управления с клавиатуры. Эта система использует специальные индикаторы с одной или несколькими буквами, появляющиеся на ленте при нажатии клавиши ALT. Данные индикаторы указывают на клавиши, которые соответствуют элементам управления.

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

Выбор вкладки с командами
. Чтобы осуществить это действие, необходимо выполнить следующее.

• 1. Активировать МА 2010.
• 2. Выбрать требуемую вкладку.

• 1. Активировать МА 2010.
• 2. Нажать и отпустить клавишу ALT. После этого отобразятся подсказки по доступу с клавиатуры.
• 3. Щелкнуть клавишу или клавиши, которые указаны в подсказке возле требуемой вкладки.

Существует несколько вариантов исполнения команд. Самый простой из них – это использование комбинаций клавиш, которые связаны с командами. Комбинациями клавиш из предшествующей версии МА можно воспользоваться и в МА 2010.

Выполнение команды:

• 1) активировать МА 2010;
• 2) выбрать вкладку с требуемой командой;
• 3) нажать элемент управления, который соответствует команде. Если комбинация клавиш для данной команды уже известна из предшествующей версии МА, нажмите ее;

• 1) нажать и отпустить клавишу ALT. Отобразятся подсказки по доступу с клавиатуры;
• 2) щелкнуть клавишу или клавиши, которые указаны в подсказке, связанной с требуемой командой.

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

Таблица 3.1

Вкладки и команды Access 2010

Вкладка команд	Возможные действия
	Выбор другого представления
	Копирование и вставка данных из буфера обмена
	Задание свойств текущего шрифта
	Установка текущего выравнивания шрифта
	Применение форматирования к полю MEMO
	Работа с записями (обновление, создание, сохранение, удаление, итоги, орфография, дополнительно)
	Сортировка и фильтрация записей
	Поиск записей
Создание	Создание пустой таблицы
	Создание таблицы на основе шаблона
	Создание списка на сайте SharePoint, а также связанной с этим списком таблицы в текущей базе данных
	Создание пустой таблицы в режиме конструктора
	Создание формы на основе активной таблицы или запроса
	Создание сводной таблицы или диаграммы
	Создание отчета на основе активной таблицы или запроса
	Создание запроса, макроса, модуля или модуля класса
Внешние данные	Импорт или связывание внешних данных
	Экспорт данных
	Сбор и обновление данных по электронной почте
	Создание сохраненных операций импорта и экспорта
	Запуск диспетчера связанных таблиц
Работа с базами данных	Перенос некоторых или всех частей базы данных на новый или существующий сайт SharePoint
	Запуск редактора Visual Basic или выполнение макроса
	Создание и просмотр отношений между таблицами
	Показ или скрытие зависимостей объектов
	Запуск архивариуса или анализ производительности
	Перемещение данных в Microsoft SQL Server или базу данных Access (только таблицы)
	Управление надстройками Access
	Создание или изменение модуля VBA

Кроме обычных вкладок команд в МА 2010 появились также контекстные вкладки (рис. 3.26). В соответствии с контекстом (т.е. с тем, каким объектом пользователь занят в данный момент и какие именно действия он исполняет) рядом с обычными вкладками команд могут отображаться контекстные вкладки.

Рис. 3.26.

Для активации контекстной вкладки с командами
нужно сделать следующее:

Нажать контекстную вкладку;

• нажать и отпустить клавишу ALT. Отобразятся подсказки по доступу с клавиатуры;
• щелкнуть клавишу или клавиши, которые указаны в подсказке около контекстной вкладки.

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

Коллекции
. Кроме всего прочего на ленте находится элемент управления, который получил название Коллекция
. Этот элемент был создан для привлечения внимания к требуемым результатам. Коллекция
– это элемент управления, который не только показывает команды, но еще и отображает результат исполнения этих команд (рис. 3.27). Главная цель создания этого элемента состоит в том, чтобы дать пользователю возможность найти и выбрать необходимые действия в МА 2010 по виду, сосредоточившись на результате, а не на самих командах.

Рис. 3.27.

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

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

Скрытие и восстановление ленты.

• 1. Дважды щелкнуть выделенную вкладку команд.
• 2. Чтобы восстановить ленту, опять дважды щелкнуть текущую вкладку команд.

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

Настройка панели быстрого доступа.
Для осуществления этого действия нужно выполнить следующее.

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

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

• 3. В диалоговом окне Параметры Access
  выбрать команду или команды, которые необходимо добавить, и щелкнуть кнопку Добавить.
  
• 4. Чтобы удалить команду, необходимо выделить ее в перечне команд, который находится справа, и щелкнуть кнопку Удалить.
  Кроме того, существует возможность просто дважды щелкнуть команду в перечне.
• 5. Когда действия по удалению команды завершены, щелкнуть кнопку ОК.
  

Когда открываются уже существующие или вновь созданные базы данных, наименования объектов базы данных отображаются в области навигации (рис. 3.28). К объектам базы данных можно отнести таблицы, формы, отчеты, страницы, макросы и модули. Область навигации по сути выполняет функции окна базы данных, которое присутствовало в предыдущих версиях МА, т.е. если в предыдущих версиях программы для запуска и выполнения задач служило окно базы данных, то в МА 2010 для этого используется область навигации. Например, для добавления строки в таблицу в режиме таблицы необходимо открыть таблицу из области навигации. В веб-браузерах область навигации обычно недоступна. Для того чтобы воспользоваться ей в веб-базе данных, сначала необходимо открыть базу данных в Access.

Рис. 3.28.

Для открытия объекта базы данных или применения к нему команды нужно кликнуть его ПКМ и выбрать команду в контекстном меню. Команды контекстного меню отображаются в зависимости от типа объекта.

Открытие объекта базы данных (например, таблицы, формы или отчета).

Дважды нажать объект в области навигации;

Отметить объект в области навигации и щелкнуть клавишу ВВОД;

В области навигации отметить объект ПКМ и выбрать в контекстном меню команду Открыть.

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

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

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

Отображение и скрытие области навигации.
Для осуществления этого действия нужно выполнить следующее:

Щелкнуть кнопку в правом верхнем углу области навигации или клавишу F11.

Для отмены отображения области навигации по умолчанию

нужно выполнить следующее:

• – на вкладке Файл
  выбрать пункт Параметры.
  Отобразиться диалоговое окно Параметры
  Access;
• – в левой области отметить пункт Текущая база данных;
  в разделе Переходы
  убрать флажок Область переходов
  и щелкнуть кнопку ОК.
  

Начиная с Access 2007, для отражения объектов базы данных в программе появилась возможность пользоваться вкладками документов, а не перекрывающимися окнами (рис. 3.29). Это более удобный инструмент. Отображение и скрытие вкладок документов можно настроить при помощи параметров МА 2010. Если пользователь изменяет эти параметры, нужно закрыть и снова открыть базу данных, тогда изменения войдут в силу.

Рис. 3.29.

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

• 1. На вкладке Файл
  щелкнуть кнопку Параметры.
  Отобразится диалоговое окно Параметры
  Access.
• 2. В левой области отметить элемент Текущая база данных.
  
• 3. В разделе Параметры приложения
  в группе Параметры окна документа
  установить переключатель в положение Вкладки.
  
• 4. Установить или убрать флажок Если флажка нет, вкладки документов отключены.
• 5. Щелкнуть кнопку ОК.

Параметр является индивидуальным, т.е. его нужно изменять отдельно для каждой базы данных. Если пользователь изменяет параметр то нужно закрыть и снова открыть базу данных, тогда изменения вступят в силу. Базы данных, созданные с помощью МА 2007 или МА 2010, показывают вкладки документов по умолчанию. В базах данных, созданных в предшествующих версиях МА, по умолчанию используются перекрывающиеся окна.

Строка состояния.
В МА 2010 внизу окна может находиться строка состояния. Как и в предыдущих версиях МА, этот стандартный компонент пользовательского интерфейса используется для отражения сообщений о состоянии, свойств, индикаторов хода выполнения и т.д. В МА 2010 строка состояния дает возможность доступа к двум стандартным функциям, отображающимся в строке состояния и в других программах Office 2010: управлению окнами и изменению масштаба.

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

Отобразить или убрать строку состояния можно в диалоговом окне Параметры Access.

Отображение и скрытие строки состояния.
Для осуществления этого действия нужно выполнить следующее.

• 1. На вкладке Файл
  найти пункт Параметры.
  Отобразится диалоговое окно Параметры Access.
  
• 2. Слева отметить пункт Текущая база данных.
  
• 3. В разделе Параметры приложений
  поставить или убрать флажок Строка состояния.
  Если флажка нет, то строка состояния не отображается.
• 4. Щелкнуть кнопку ОК.
  

Для форматирования текста в версиях МА, которые были выпущены до МА 2007, обычно использовались меню или панель инструментов Форматирование.
В МА 2010 форматировать текст стало удобнее, так как была создана мини-панель инструментов (рис. 3.30). Если выделить текст с целью форматирования, над ним автоматически появится минипанель инструментов. При движении указателя мыши по направлению к мини-панели она становится более четкой, и тогда ее можно применить для изменения начертания, размера и цвета шрифта и т.д. Когда курсор мыши удаляется, мини-панель инструментов постепенно исчезает, т.е. если в мини-панели инструментов нет необходимости, она исчезает.

Рис. 3.30.

Форматирование текста с помощью мини-панели инструментов.

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

Если необходимо прояснить какие-то вопросы, нужно вызвать справку, нажав клавишу F1 или щелкнув вопросительный знак в правой части ленты (рис. 3.31).

Рис. 3.31.

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

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

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

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

В этой статье

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

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

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

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

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

Если общая сетевая папка отсутствует, ее нужно настроить.

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

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

1. Запустите Access и на вкладке Файл
   выберите пункт Параметры
   .

   В окне Параметры Access
   выберите пункт Параметры клиента
   .

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

На компьютере каждого пользователя создайте ярлык для файла базы данных. В диалоговом окне “Свойства ярлыка” укажите путь к файлу базы данных в свойстве Цель
, используя вместо буквы подключенного диска UNC-адрес. Например, вместо пути F:sample.accdb
укажите путь \имя_компьютераshared.accdb
.

Примечание:
Это действие пользователи могут выполнить самостоятельно.

Совместное использование разделенной базы данных

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

Преимущества разделения базы данных

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

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

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

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

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

Если этот метод вам подходит, перейдите к инструкциям в статье Разделение базы данных Access .

Совместное использование базы данных на сайте SharePoint

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

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

Примечание:
Если на компьютере установлено приложение Access, можно использовать клиентские объекты из веб-базы данных, а не только объекты веб-базы данных.

Службы Access предоставляют платформу для создания без данных, которые можно использовать в Интернете. Веб-базы данных конструируются и публикуются с использованием Access 2010 и SharePoint, после чего можно использовать веб-базу данных через веб-браузер.

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

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

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

Сохранение базы данных в библиотеке документов

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

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

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

На вкладке Файл
выберите пункт Сохранить как
.

Примечание:
Если вы используете Access 2010, выберите элементы Файл
> Сохранить и опубликовать
> Сохранить базу данных как
> SharePoint
.

В диалоговом окне Сохранение в SharePoint
перейдите к соответствующей библиотеке документов.

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

Дополнительные сведения см. в статьях Публикация в службах Access и Импорт и связывание данных со списком SharePoint .

Совместное использование базы данных путем связывания со списками SharePoint

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

Этот способ включает три основных действия.

Перемещение данных в списки SharePoint.

Создание ссылок на эти списки.

Распространение файла базы данных.

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

Использование мастера экспорта таблиц в SharePoint

На вкладке Работа с базами данных
в группе Перенос данных
щелкните элемент SharePoint
.

Примечание:
Этот элемент доступен только в том случае, если файл базы данных сохранен в формате ACCDB.

Следуйте указаниям мастера экспорта таблиц в SharePoint; в частности, укажите расположение сайта SharePoint. Чтобы отменить процесс, нажмите кнопку Отмена
.

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

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

Когда все действия мастера будут завершены, нажмите кнопку Готово
.

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

Примечание:
Чтобы просмотреть списки на сайте SharePoint, щелкните в области быстрого запуска кнопку Списки
или выберите пункт Просмотреть все содержимое узла
. Может потребоваться обновить страницу в веб-браузере. Чтобы отобразить списки в области быстрого запуска на сайте SharePoint или изменить другие параметры (например, включить отслеживание версий), можно изменить параметры списков на сайте SharePoint. Дополнительные сведения см. в справке для сайта SharePoint.

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

Совместное использование базы данных можно организовать с помощью приложения Access и сервера баз данных (например, сервера SQL Server). Этот способ обеспечивает много преимуществ, но для него требуется дополнительное программное обеспечение – сервер баз данных.

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

Преимущества совместного использования базы данных с помощью сервера баз данных

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

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

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

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

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

Основные этапы использования Access с сервером баз данных

Факторы, которые следует учитывать при выборе метода

Требования метода	Разделение базы данных	Сетевая папка	Сайт SharePoint	Сервер баз данных
Необходимость наличия программного обеспечения сервера баз данных
Необходимость наличия SharePoint
Необходимость наличия служб Access на сервере SharePoint			Зависит от сценария: связывание со списками и сохранение в библиотеке документов не требует наличия служб Access; публикация в виде веб-базы данных или веб-приложения требует наличия служб Access.
Доступность данных		Подходит для небольших групп, если данные мало изменяются	Наилучшая. Подходит для сценариев автономного использования.	Наилучшая
Безопасность	Зависит от дополнительных мер	Наименее безопасный способ	Наилучшая	Наилучшая
Гибкость	Гибкий способ. Можно легко разрабатывать новые функции базы данных без нарушения работы. Пользователи могут изменять структуру в собственной копии.	Менее гибкий способ. Разработку можно осуществлять с использованием автономной копии базы данных, которая затем заменяется. Отсутствует возможность индивидуального изменения структуры базы данных пользователями.	Гибкий способ. Использование разрешений SharePoint для управления доступом и изменения структуры. Позволяет использовать некоторые объекты базы данных, например формы, на основе браузера.	Гибкий способ. Можно легко разрабатывать новые функции базы данных без нарушения работы. Пользователи могут изменять структуру объектов в собственной копии.

ПОНЯТИЕ И КЛАССИФИКАЦИЯ БАЗ ДАННЫХ

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

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

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

Рис. 7.4. Обобщенная схема использования БД для решения задач пользователей

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

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

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

Интересно, что название одной из известнейших в мире террористических группировок «Al-Quaeda» (Аль-Кайеда) в переводе с арабского языка означает «База данных». Происхождение этого названия вызвано строгим учетом сведений о членах организации.

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

К основным свойствам баз данных и средств их поддержки и организации можно отнести:

Отсутствие дублирования данных, обеспечивающее однократный ввод данных и простоту их корректировки;

Непротиворечивость данных;

Целостность базы данных;

Возможность многоаспектного доступа;

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

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

Защита данных от несанкционированного доступа средствами разграничения доступа для различных пользователей;

Возможность модификации структуры БД без повторной загрузки данных;

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

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

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

Рис. 7.5. Классификация баз данных

1. По способу хранения данных
выделяют два основных вида баз данных – распределенные
и централизованные.

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

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

2. По типу хранимых данных

– фактографические,

содержащие краткие сведения об описываемых объектах, представленные в строго определенном формате;

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

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

3. По режимам доступа
базы данных подразделяются на следующие виды:

1) базы данных с доступом в режиме online (online databases)

хранятся в центральном банке данных. Доступ к ним осуществляется посредством телекоммуникационного оборудования и каналов связи. К таким базам данных можно отнести внутреннюю БД предприятия, имеющего ЛВС, корпоративное хранилище данных с доступом по каналам VPN,
а также базы данных, расположенные в Internet (Internet databases).
Обращаться к ним можно в режиме реального времени, извлекать из них сведения и сохранять их на компьютере или вспомогательном запоминающем устройстве;

2) базы данных с доступом в режиме offline (offline databases)

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

4. По количеству пользователей
БД выделяют следующие виды:

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

– многопользовательские

– обеспечивают сетевое взаимодействие пользователей, которое подразделяется на два основных вида (см. раздел 4.4):

o – взаимодействие «толстый клиент» («модель файлового сервера», «модель доступа к удаленным данным»)
предполагает выделение одной из вычислительных машин сети в качестве центральной (сервер). На нем хранится совместно используемая централизованная БД. Все другие ПК сети выполняют функции рабочих станций. В случае использования «модели файлового сервера» файлы БД по запросам пользователей передаются на рабочие станции, где и производится обработка информации. При большой интенсивности запросов к одним и тем же файлам производительность ЛВС падает. В случае использования «модели доступа к удаленным данным» на рабочей станции клиента и выделенном сервере устанавливается специализированная СУБД, которая подразделяется на две части: клиентскую и серверную. Запрос, передаваемый клиентом серверу БД, порождает поиск, извлечение и передачу не файлов, как в предыдущей модели, а извлеченных данных. Тем самым количество передаваемой по сети информации уменьшается во много раз. Однако основные вычислительные нагрузки, как и
в первом случае, ложатся на рабочую станцию клиента, где происходит обработка и представление данных;

o – взаимодействие «тонкий клиент» («модель сервера баз данных» «модель сервера приложений») осуществляется в двух вариантах. При использовании «модели сервера баз данных» поиск и обработка данных осуществляется на сервере БД. Клиент имеет ограниченные программные ресурсы, ориентированные только на представление информации. Во втором варианте, который осуществляется в трехуровневой архитектуре, выделяют 2 сервера – сервер БД и сервер приложений. В сервере БД осуществляется поиск искомых данных, а в сервере приложений их обработка. На рабочей станции клиента выполняется только представление данных. Таким образом, понятие «тонкий клиент» указывает, что основные вычислительные нагрузки ложатся на серверный компонент сети.

5. По обслуживанию базами данных решаемых задач
выделяют два основных вида БД:

– локальные БД


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

– интегрированные БД


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

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

Мульти-БД(неоднородные БД)

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

6. По форме организации данных
выделяют:

– базы данных

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

– базы знаний

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

7. По модели баз данных
выделяют следующие виды БД:

– плоские


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

– иерархические


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

– сетевые

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

– реляционные


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

– объектно-ориентированные,


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

– объектно-реляционные

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

– модель данных «объектов-ролей

»
включает в себя два основных понятия – «объекты» и «роли», над которыми выполняются манипуляции. Модель используется для понятийного моделирования и в настоящее время не получила широкого распространения;

– многомерные БД


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

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

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

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

– «один к одному» (1–1),

когда одна запись может быть связана только с одной записью;

– «один ко многим» (1–М) –

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

);

– «многие ко многим» (М–М) –

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

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

и реляционную

.

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

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

К основным типам структур файловой модели относятся:

– Поле

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

– Тип поля

определяет множество значений, которые может принимать данное поле в различных записях. В файловых и реляционных моделях используются несколько основных типов полей. Поля, значения которых могут быть только числами, относятся к полям числового
типа, которые в свою очередь делятся на поля вещественного
типа, поля целого
типа, поля денежного
типа данных и т.д. Символьный
тип поля представляет символьные последовательности (слова, коды и т.п.). Поля типа «дата/время
» предназначены для хранения времени, дат и дат совместно с временем в разных форматах представления. Логический
тип данных соответствует полю, которое может принимать два значения: «да» – «нет» или «истина» – «ложь» («true» – «false»).

– Запись

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

– Экземпляр записи

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

– Ключ записи

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

В моделях данных выделят два вида ключей – первичный
и вторичный.

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

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

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

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

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

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

Рисунок 7.6 – Пример документа и его структуры

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

Иерархическая модель данных
является наиболее простой и появилась первой среди всех моделей БД, организованных в среде СУБД. Появление иерархической модели связано с тем, что в различных областях человеческой деятельности очень многие связи соответствуют иерархии, когда один объект выступает как родительский, а с ним может быть связано множество подчиненных объектов. Самой известной иерархической системой позволяющей создавать иерархические БД является система IMS (Information Management System)
фирмы IBM, используемая в свое время для поддержки лунного проекта «Аполлон» («Apollon»)
, в процессе реализации которого необходимо было управлять огромным количеством деталей, иерархически связанных между собой.

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

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

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

Иерархическое дерево имеет только один узел (корневой или корень), не подчиненный никакому другому узлу и находящийся на самом верхнем – первом уровне;

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

Рисунок 7.7 – Иерархическая модель данных

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

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

Рисунок 7.8 – Пример иерархической базы данных

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

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

Сетевая модель данных
является развитием иерархической модели. Она появилась в 1971 г., когда группа DTBG (Database Task Group)
представила в американский национальный институт стандартов отчет, который послужил в дальнейшем основой для разработки сетевых систем управления базами данных. Стандарт сетевой модели впервые был определен в 1975 году организацией CODASYL (Conference of Data System Languages),
которая определила базовые понятия модели и формальный язык описания.

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

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

Рисунок 7.9 – Сетевая модель данных

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

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

Рисунок 7.10 – Пример сетевой базы данных

К особенностям организации сетевой модели относятся:

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

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

В любом наборе может быть только один владелец;

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

Тип записи может не входить ни в какой тип наборов.

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

К достоинствам сетевых моделей можно отнести:

Отсутствие дублирования данных в различных элементах модели;

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

В сетевых моделях допустимы всевозможные запросы и т.д.

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

Реляционная модель данных.
Основателем реляционной модели является сотрудник фирмы IBM Э.Ф. Кодд, который в 1970 году в своей статье вывел заключение о том, что любое представление данных может быть сведено к совокупности двумерных таблиц, называемых в математике «отношениями» (relations – отношения). Отсюда и пошел термин, определяющий модель данных, представленную в виде таблиц – «реляционная».

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

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

Каждый столбец имеет уникальное имя;

Одинаковые строки в таблице отсутствуют;

Порядок следования строк и столбцов в таблице может быть произвольным.

Структурными объектами обработки реляционной БД являются следующие информационные единицы (см. рис. 7.11):

Рисунок 7.11 – Основные структурные элементы реляционной базы данных

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

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

Экземпляр записи
– отдельная реализация записи, содержащая конкретные значения ее полей (конкретная строка реляционной таблицы).

Таблица (отношение)
– заданная структура полей, состоящая из конечного набора однотипных записей.

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

– однозначная идентификация записи
–
запись должна однозначно определяться значением ключа;

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

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

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

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

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

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

Рисунок 7.12 – Реляционная БД поставки товаров по договорам

База данных состоит из шести таблиц – «Заказчики», «Данные о заказчике», «Договоры», «Изделия», «Заказы изделий», «Поставка изделий».

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

Таблица «Изделия» (рис. 7.12 б) содержит код поставляемых изделий и их номер.

Таблица «Данные о заказчике» (рис. 7.13 в) содержит контактные данные о заказчике (название организации и контактный телефон).

Таблица «Договоры» (рис. 7.12 г) описывает заключенные с заказчиками договоры и включает в себя код договора, код заказчика и номер заключенного договора.

В таблице «Заказы изделий» (рис. 7.12 д) отражено количество заказанных изделий по каждому договору.

В таблице «Поставка изделий» (рис. 7.12 е) отражено количество поставленных изделий по каждому заказу и дата отгрузки.

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

Рисунок 7.13 – Связи в таблицах реляционной базы данных

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

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

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

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

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

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

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

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

Первая нормальная форма (1NF):

Запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию);

Запрещает множественные столбцы (содержащие значения типа списка);

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

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

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

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

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

Пятая нормальная форма (5NF)
представляет собой форму таблицы, в которой устранены зависимости соединения. Данная форма в большей степени является теоретическим исследованием и практически не применяется при реальном проектировании баз данных. Это связано со сложностью определения самого наличия зависимостей «проекции – соединения», поскольку утверждение о наличии такой зависимости должно быть сделано для всех возможных состояний БД.

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

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

В реляционной модели БД явно выражены три основных вида взаимосвязей между атрибутами (полями) – «один к одному», «один ко многим», «много ко многим».

«один к одному»,

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

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

установлена связь типа «один к одному» (см. рис. 7.14).

Рисунок 7.14 – Связь «один к одному» в таблицах реляционной БД

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

Разделение очень «широкой» таблицы с целью повышения производительности (чтобы СУБД не обрабатывала большую таблицу там, где по большинству запросов надо вернуть всего несколько полей);

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

Таблицы находятся в отношении «один ко многим»,

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

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

Например, рассмотренные таблицы «Договоры» и «Заказы изделий» находятся в отношении «один ко многим». При этом на стороне «один» находится таблица «Договоры», а на стороне «многие» – «Заказы изделий». Связь устанавливается по полю Код договора
. Каждая запись таблицы «Договоры» может иметь много связанных с ней записей в таблице «Заказы изделий» (т.к. в данном случае по одному договору заказчикам поставляются несколько видов изделий), иначе говоря, в таблице «Заказы изделий» может быть много строк с заданным значением в поле Код договора
(например, по различным кодам изделий). В то же время, если взять любую строку в таблице «Заказы изделий», то для нее найдется не более одной строки в таблице «Договоры» с таким же значением в поле Код договора
(см. рис. 7.15).

Рисунок 7.15 – Связь «один ко многим» в таблицах реляционной БД

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

Таблицы находятся в отношении «многие ко многим»,

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

Такая связь всегда реализуется с помощью третьей (связующей) таблицы. Например, в рассмотренной выше задаче для связи таблиц «Договоры» и «Изделия» сформирована таблица «Заказы изделий» (см. рис. 7.16).

Рисунок 7.16 – Связь «многие ко многим» в таблицах реляционной БД

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

При этом если рассмотреть таблицы «Договоры» и «Заказы изделий», то между ними установлено отношение «один ко многим», в котором таблица «Договоры» является главной, а таблица «Заказы изделий» – подчиненной. Аналогично между таблицами «Изделия» и «Заказы изделий» установлена связь «один ко многим», в которой таблица «Изделия» является главной.

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

Базовые операции:

– ограничение
– исключение из таблицы некоторых строк;

– проекция
– исключение из таблицы некоторых столбцов;

– декартово произведение
– из двух таблиц получается третья по принципу декартова произведения, когда результат содержит все атрибуты из таблиц-сомножителей (количество полей новой таблицы равно сумме количества полей в каждой из таблиц-сомножителей) и все возможные сочетания записей (количество записей в новой таблице равно произведению количества записей в таблицах-сомножителях). Например, умножив таблицу «Заказчики» на таблицу «Договоры» получим 6 полей и 9 записей. Потом оставляем только те записи, где код заказчика совпадает (3) и нужные нам поля. Таким способом получаем сведения о заказчиках для каждого договора;

– объединение
– объединение множеств строк двух таблиц;

– разность
– разность множеств строк двух таблиц;

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

Производные операции:

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

– пересечение
представляет собой пересечение множеств строк двух таблиц;

– деление
позволяет отвечать на вопросы типа – какой элемент данных соответствует элементам определенного атрибута (столбца)? Например, какие заказчики приобретают изделие кода СТУ1432?

– разбиение
позволяет отвечать на вопросы типа – какие несколько элемен-

Тов соответствуют элементам определенного атрибута (столбца)? Напри-

Мер, какие три заказчика приобретают изделие кода СТУ1432?

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

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

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

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

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

Простота представления данных, благодаря табличной форме;

Гибкость системы защиты – для каждой таблицы может быть задана правомерность доступа;

Минимальная избыточность данных;

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

Универсальность процедур обработки данных.

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

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

Объектно-ориентированная модель данных (ООМД) –
это один из вариантов расширенной реляционной модели.

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

В 1991 г. был образован консорциум ODMG (тогда эта аббревиатура означала Object Database Management Group – группа управления объектными базами данных, но впоследствии приобрела более широкую трактовку – Object Data Management Group – группа управления объектными данными). Консорциум ODMG тесно
связан с гораздо более многочисленным консорциумом OMG (Object Management Group – группа управления объектами), который был образован двумя годами раньше. Основной исходной целью ODMG была выработка промышленного стандарта объектно-ориентированных баз данных (общей модели). За основу была принята базовая объектная модель OMG COM (Core Object Model – объектная модель документа). В течение своего существования ODMG опубликовала несколько базовых версий стандарта объектно-ориентированных баз данных.

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

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

Таблица 7.1 – Основные понятия объектно-ориентированной модели

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

Рисунок 7.17 – Пример логической структуры объектно-ориентированной БД

склада предприятия-поставщика изделий

На рис. 7.17 объект типа Склад является родительским для объектов классов Заказчик, Поставка и Изделие. Различные объекты типа Материал могут иметь одного или разных родителей. Объекты типа Материал, имеющие одного и того же родителя, должны различаться, например, видом материала (уникален для каждого материала), но имеют одинаковые значения свойства – Отделка.

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

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

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

Наследование
, наоборот, распространяет область видимости свойства на всех потомков объекта. Так, всем объектам типа Материал, являющимся потомками объекта типа Изделие, можно приписать свойства объекта-родителя: код, название, отделка и тип изделия. Если необходимо расширить действие механизма наследования на объекты, не являющиеся непосредственными родственниками (например, между двумя потомками одного родителя), то в их общем предке определяется абстрактное свойство типа abs. Так, определение абстрактных свойств Кода и № поставки в объекте Склад приводит к наследованию этих свойств всеми дочерними объектами Заказчик, Поставка и Материал. Не случайно, поэтому значения свойства Кода заказчика классов Заказчик и Поставка являются одинаковыми – АО126.

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

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

К достоинствам объектно-ориентированной модели обычно относят:

Возможность для пользователя определять свои сложные типы данных;

Возможность отображения информации о сложных взаимосвязях объектов;

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

Наличие наследуемости свойств объектов;

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

К недостаткам объектно-ориентированной модели можно отнести:

Отсутствие строгих определений – разное понимание терминов и различия в терминологии;

Недостаточная исследованность и теоретическая проработка модели;

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

Высокая понятийная сложность;

Низкая скорость выполнения запросов.

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

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

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

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

К основным недостаткам объектно-реляционной модели являются:

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

Сложность терминологии;

Ограниченное количество приложений, на которые ориентирована объектно-реляционная модель данных;

Сравнительно низкая производительность и т.д.

В период с 1989 по 1995 гг. авторские группы, включающие известных специалистов в области баз данных, подготовили и опубликовали три документа, которые отражали точки зрения авторов относительно перспектив развития технологии БД. С их легкой руки, начиная с первого, эти документы получили название манифестов, что, в общем то, отражало их суть: в каждом провозглашался набор идей и требований, на которых, по мнению авторов, должны были базироваться системы БД следующего поколения. Интересно отметить различия между коллективами авторов каждого из манифестов. «Манифест систем объектно-ориентированных баз данных» (Первым манифестом) написан академическими исследователями; почти все они являются профессорами различных университетов. Конечно, это нашло свое отражение в стиле первого манифеста – очень мягком и умеренно рекомендательном (хотя по своему духу предложения этого манифеста были весьма радикальными).

Авторы документа «Системы баз данных третьего поколения: Манифест» (Второго манифеста) являлись представителями индустриально-ориентированных исследований. Второй манифест написан в более жестком стиле и во многом направлен на защиту инвестиций крупных компаний-производителей программного обеспечения SQL-ориентированных СУБД. Конечно, Второй манифест во многом представлял собой реакцию индустрии на революционные предложения Первого манифеста. Эти предложения подвергались критике, которая заключалась в том, что, можно добиться аналогичных результатов, не производя революцию в области технологии
БД, а эволюционно развивая технологию SQL-ориентированных СУБД. «Третий манифест» являлся одновременно наиболее консервативным и наиболее радикальным. Консервативность Третьего манифеста заключается в том, что его авторы всеми силами утверждают необходимость и достаточность использования в системах БД следующего поколения классической реляционной модели данных. Радикальность состоит в том, что (a) авторы полностью отрицают подходы, предлагаемые в первых двух манифестах, расценивая их как необоснованные, плохо проработанные, избыточные и даже вредные. Фактически, авторы полностью отбрасывают технологию, созданную индустрией баз данных за последние 25 лет, и предлагают вернуться к истокам реляционной модели данных, т.е. к начальным статьям Э. Кодда, который в 1980 году за свою реляционную модель данных получил премию Тьюринга.

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

Модель данных «объектов-ролей»
является моделью данных, имеющей конкретную программную реализацию – InfoModeller. Модель «объектов-ролей» была предложена еще в начале 70-х годов и в настоящее время реализуется фирмой Asymetrix. В отличие от реляционной модели в ней нет атрибутов, а основные понятия – это объекты и роли, описывающие их. Роли могут быть как «изолированные», присущие исключительно какому-нибудь объекту, так и существующие как элемент какого-либо отношения между объектами. Модель «объектов-ролей» отличается от реляционной следующими особенностями:

Модель служит для понятийного моделирования;

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

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

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

Системы оперативной (транзакционной) обработки (OLTP-приложения);

Системы аналитической обработки (OLAP-приложения).

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

Многомерные модели рассматривают данные как кубы, которые являются обобщением таблиц на любое число измерений. Кроме того, кубы поддерживают иерархию измерений и формул без дублирования их определений. Набор соответствующих кубов составляет многомерную базу данных (хранилище данных). Кубами легко управлять, добавляя новые значения измерений. Теоретически куб может иметь любое число измерений. На практике чаще всего кубы данных имеют 4–12 измерений, т.к. при их большем числе современный инструментарий часто сталкивается с нехваткой производительности (особенно свыше 10–15 измерений).

Многомерный подход к представлению данных появился практически одновременно с реляционным, однако, интерес к многомерным СУБД стал приобретать массовый характер с середины 90-х годов ХХ в. Толчком послужила статья Э. Кодда, выпущенная в 1993 г. В ней были сформулированы 12 основных требований к системам класса OLAP,
важнейшие из которых связаны с возможностями концептуального представления и обработки многомерных данных (См. «Инструментальные средства построения проблемно-ориентированного прикладного программного обеспечения»):

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

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

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

• Перевод

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

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

Какой функционал требуется от базы данных

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

Фото: binaryape

Отстранитесь от базы данных.
Попытайтесь подумать, что будет требоваться от сайта? Например, если требуется сделать сайт, объединяющий людей, вы, возможно, сразу начнете думать о данных, которые будут хранить пользователи. Забудьте, отложите это на потом. Лучше запишите, что пользователи и информация о них должна храниться в базе данных. А что еще? Что пользователи будут делать на вашем сайте? Будут ли они публиковать записи, загружать файлы, фотографии, писать друг другу сообщения? Следовательно, база данных должна хранить всю эту информацию: записи, файлы, фотографии, сообщения и т. д.
Как будут взаимодействовать пользователи с вашим сайтом? Будет ли у них необходимость в поиске, например, их любимых рецептов, иметь доступ к записям, доступным конкретному сообществу, искать продукты или смотреть список недавно просмотренных и купленных продуктов? В базе данных должна быть предусмотрена возможность хранить рецепты, «закрытые» записи, доступные определенному кругу пользователей, информацию о продуктах, а также возможность связи определенного продукта и пользователя.

Определение необходимых таблиц и полей

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

Используйте инструмент моделирования данных

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

Есть также более известный, качественный, на мой взгляд, инструмент – Microsoft Visio (только под Windows, цена $249.99). Но не пугайтесь, есть более дешевые альтернативы, многие из которых являются open-source проектами, в том числе два, упомянутых выше.
Ознакомьтесь с общими графическими обозначениями и стандартными визуальными элементами, необходимым для создания модели базы данных, и начните предварительное планирование с помощью блок-схем и диаграмм. Это позволит избежать логических ошибок, прежде чем будет создана уже какая-нибудь конкретная база данных.

Группировка и разделение данных

Что касается полей, также важно знать, когда группировать определенную часть данных, а когда нет. Хороший способ определить, какая информация должна быть в одном поле или наоборот, подумать, будет ли необходимость изменять какую-либо её часть? Например, нужно ли хранить адрес, разбив его на составляющие: 1) улица, 2) город, 3) штат, 4) почтовый код, 5) страна?
Это неотъемлемая часть функционала сайта (возможно, пользователи или администраторы захотят искать других пользователей по адресу или штату), или просто увеличение места, занимаемого базой данных на диске? Если это не столь важно, зачем тогда нагружать базу данных на изменение 5 полей, когда можно обновить всего лишь одно строковое поле. Более удобным может быть вариант получения этих данных из HTML-формы, где поля разделены, а уже перед добавлением адреса в базу данных объединять значения из соответствующих полей в одну строку.
Это только один пример, но всегда имейте представление о наиболее эффективные способы организации полей таблицы, когда объединять их, когда содержать отдельно, ради поддержания функциональности сайта.

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

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

· Возможности СУБД MS Access.

· Режимы работы с объектами базы данных в MS Access: оперативный режим, режим конструктора.

· Порядок построения выражений в MS Access.

· Операции с данными в таблице базы данных.

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

· Использование элементов управления в объектах базы данных: форма, отчет, запрос, страница доступа к данным.

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

· Средства автоматизации операций с объектами баз данных в СУБД Microsoft Access.

· Возможности изменения настроек и параметров СУБД MS Access.

Возможности Microsoft Access

Средствами Access можно выполнить следующие операции.

1. Проектирование базовых объектов ИС – двумерных таблиц с разными типами данных, включая поля объектов OLE.

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

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

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

· оптимизация пользовательского ввода и просмотра данных(формы);

· соединение данных из различных таблиц;

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

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

· составление печатных отчетов по данным, которые содержатся в таблицах и запросах БД.

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

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

Microsoft Access предоставляет мощные интуитивные способы совместного использования данных XML (Extensible Markup Language), независимо от платформы, формата данных, протокола, схемы и бизнес-правил. Язык XML является не только стандартной технологией передачи данных в Интернете; он быстро превращается в предпочтительную технологию обмена данными между деловыми приложениями.

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

Технология работы с MS Access

Вы можете запускать MS Access и завершать ее работу любым из стандартных способов, предусмотренных в среде Windows.

Объектом обработки MS Access является файл базы данных, имеющий произвольное имя, и расширение.MDB. В этот файл входят основные объекты MS Access: таблицы, формы, запросы, отчеты, страницы, макросы и модули.

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

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

· Включайте все необходимые сведения. Разбивайте информацию на минимальные логические компоненты. Например, имена сотрудников удобно разбить на два поля – «Имя» и «Фамилия», что облегчит сортировку по фамилиям.

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

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

· Не создавайте поля, содержащие аналогичные данные. Например, если создать в таблице «Поставщики» поля «Товар!», «Товар2»и «ТоварЗ», будет трудно найти поставщиков, поставляющих конкретный товар. Кроме того, придется изменять структуру базы данных, если появится поставщик, предлагающий четыре товара. Достаточно будет одного поля для товаров, если поместить это поле в таблицу «Товары», а не в таблицу «Поставщики».

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

· Включайте каждое поле только в одну таблицу.

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

1. Определение полей с уникальными значениями в каждой записи
   . Для связывания в Microsoft Access сведений, хранящихся в разных таблицах, например, для связывания клиента со всеми его заказами, каждая таблица базы данных должна содержать поля или набор полей, однозначно определяющих каждую запись. Такое поле или набор полей называют первичным ключом
   
   .
2. Определение связей между таблицами
   . После разбиения сведений на таблицы и определения полей первичного ключа необходимо выбрать способ, которым Microsoft Access будет вновь объединять связанные сведения. Для этого следует определить связи между таблицами базы данных Microsoft Access. При этом полезно изучить связи в существующей базе данных с хорошо организованной структурой, например, в учебной базе данных «Борей».
3. Усовершенствование структуры базы данных
   . После создания нужных таблиц, полей и связей необходимо еще раз просмотреть структуру базы данных и выявить возможные недочеты. Желательно это сделать на данном этапе, пока таблицы не заполнены данными.

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

1. Ввод данных и создание других объектов базы данных
   . Если структуры таблиц отвечают поставленным требованиям, то можно ввести все данные. Затем можно создать все необходимые объекты базы данных – запросы, формы, отчеты, страницы доступа к данным, макросы и модули.
2. Использование средств анализа Microsoft Access. В Microsoft Access существуют два инструмента, помогающие усовершенствовать структуру базы данных Microsoft Access. Мастер анализа таблиц позволяет проанализировать структуру таблицы, предложить подходящие новые структуры и связи, а также разделить таблицу на новые связанные таблицы, если это имеет смысл. Анализатор быстродействия исследует всю базу данных и дает рекомендации по ее улучшению, а также может выполнить эти рекомендации.

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

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

Для создания новой базы данных выберите в меню Файл
команду Создать
, затем в панели задач Создание файла
выберите вариант Новая база данных
. После этого на экране появляется стандартный файлер, в котором следует открыть нужную папку и задать имя создаваемого файла базы данных. Например, «группа.MDB». Создав файл, Access раскрывает пустое окно базы данных, и в этом окне можно будет проводить все операции – создавать и манипулировать объектами БД. MS Access является многооконным приложением, однако в любой момент может быть открыта только одна база данных. Именно ее окно является главным окном документа в приложении Access, и его закрытие означает закрытие соответствующего файла.MDB.

Рис. 1. Окно базы данных

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

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

Основные понятия MS Access. Объекты MS Access

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

Форма не является самостоятельным объектом MS Access: она просто помогает нам вводить, просматривать и модифицировать информацию в таблице или запросе. Запросы и отчеты выполняют самостоятельные функции: выбирают, группируют, представляют, печатают информацию. Страницы доступа к данным представляют собой специальный тип web-страниц, предназначенный для просмотра и работы через Интернет, или интрасеть с данными, хранящимися в базе данных Microsoft Access или Microsoft SQL Server. С помощью страницы пользователи могут вводить, редактировать и удалять данные из базы данных.

Каждый объект MS Access имеет имя. В Microsoft Access действуют следующие ограничения на имена полей, элементов управления и объектов (табл. 1).

· имя должно содержать не более 64 символов;

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

· не должно начинаться с символа пробела;

· не должно включать управляющие символы (с кодами ASCII отО до 31);

· не должно включать прямые кавычки (“) в именах таблиц, представлений и хранимых процедур в проекте Microsoft Access.

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

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

Таблица 1 Типы данных, которые могут иметь поля в Microsoft Access

Тип данных	Использование	Размер
Текстовый	Текст или комбинация текста и чисел (например, адреса), а также числа, не требующие вычислений, (например, номера телефонов, инвентарные номера или почтовые индексы)	До 255 символов
Числовой	Числовые данные, используемые для математических вычислений, за исключением финансовых расчетов (для них следует использовать тип «Денежный»). Для более точного определения типа числа используйте свойство Размер поля (FieldSize)	1,2,4 или 8 байт. 16 байт только для кодов репликации (GUID)
Поле MEMO	Длинный текст или числа, например, примечания или описания	До 64 000 символов
Дата/время	Даты и время	8 байт
Денежный	Значения валют. Денежный тип используется для предотвращения округлений во время вычислений. Предполагает до 15 символов в целой части числа и 4 – в дробной	8 байт
Счетчик	Автоматическая вставка последовательных (увеличивающихся на 1) или случайных чисел при добавлении записи. Этот тип поля удобно применять для первичного ключа таблицы. В качестве значений таких полей Access автоматически выбирает целые порядковые номера (1,2,…). В дальнейшем номер, присвоенный записи при ее создании, не изменяется (независимо от удаления, вставки новых записей и т.п.)	4 байта. 1 6 байт только для кодов репликации (GUID)
Логический	Поля, содержащие только одно из двух возможных значений, таких, как «Да/Нет», «Истина/Ложь», «Вкл/Выкл»	1бит
Поле объекта OLE	Объекты (например, документы Microsoft Word, электронные таблицы Microsoft Excel, рисунки, звуки и другие двоичные данные), созданные в других программах, использующих протокол OLE. Объекты могут быть связанными или внедренными в таблицу Microsoft Access. Для отображения объекта OLE в форме или отчете необходимо использовать присоединенную рамку объекта	До 1 гигабайта (ограничено объемом диска)
Гиперссылка	Поле, в котором хранятся гиперссылки, имеющие вид пути или URL-адреса	До 64 000 символов
Мастер подстановок	Создает поле, позволяющее выбрать значение из другой таблицы или из списка значений, используя поле со списком. При выборе данного параметра в списке типов данных запускается мастер для автоматического определения этого поля	Тот же размер, который имеет первичный ключ, являющийся также и полем подстановок; обычно – 4 байта

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

1. оперативный режим, когда просматривается, изменяется или выбирается информация;

2. режим конструктора, когда создается или изменяется макет, структура объекта (например, структура таблицы).

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

В окне базы данных под стандартной панелью инструментов расположена панель с кнопками «Открыть», «Конструктор» и «Создать», а также кнопки изменения вида представления объектов базы данных. В левой части окна отображается список вкладок (по числу объектов Access) с корешками: Таблица, Запрос, Форма, Отчет, Страницы, Макрос
и Модуль
. Если выбрана какая-либо вкладка, то в окне базы данных отображается список существующих объектов этого типа данной БД. Например, если выбрать вкладку Таблица
, то в окне отображается список таблиц открытой базы данных. Чтобы открыть таблицу, надо выделить ее имя в этом списке и нажать кнопку «Открыть». Чтобы включить в БД новую таблицу, надо нажать кнопку «Создать». Чтобы исправить макет существующей таблицы, надо выделить ее имя в списке и нажать кнопку «Конструктор». Такие же операции выполняются со всеми другими объектами базы данных Access.

Набор пунктов горизонтального меню и состав панелей инструментов зависят от типа и режима окна документа, которое в данный момент активно. Например, окно таблицы в оперативном режиме имеет кнопки «Вырезать», «Сортировать по возрастанию» и др., а в режиме конструктора – кнопки «Свойства», «Определить ключ» и др. Работа с панелями инструментов подчиняется стандарту Windows.

Примечание. Поля типов «Числовой», «Дата/время», «Денежный» и «Логический» имеют предопределенные форматы вывода данных. Формат вывода можно выбрать в ячейке Свойства Формат поля. Можно также создать собственные форматы вывода для всех типов данных, кроме объектов OLE.

Технология разработки базы данных

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

Для создания базы данных запустите MS Access и выберите в меню Файл
команду Создать
, затем в панели задач Создание файла выберите вариант Новая база данных. После этого в окне Файл новой базы данных
откройте нужную папку, например, Новая папка, и задайте имя создаваемого файла базы данных, например, «Группа.MDB».

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

Для создания таблицы выберите в списке вкладок в левой части окна базы данных вкладку Таблица
. После этого в окне базы данных будут отображены ярлыки вариантов создания таблицы: в режиме конструктора, с помощью мастера и путем ввода данных. Дважды щелкнув мышью по строке «Создание таблицы в режиме Конструктор», откройте окно таблицы в режиме Конструктор, как показано на рис. 2.

Рис. 2. Определение параметров поля таблицы в режиме Конструктор

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

В столбце Имя поля введите произвольное имя поля, а в следующем столбце укажите тип данных для этого поля. Тип данных можно выбрать из раскрывающегося списка. Как только курсор оказывается в столбце Тип данных, в нижней части окна возникает бланк Свойства поля (характеристики данного поля). Он представляет собой перечень свойств (слева – название свойства, справа – значение этого свойства) с окном подсказки по каждому свойству. Перечень свойств меняется в зависимости от типа данных, который в текущий момент отображается в столбце Тип данных. Щелкнув мышью на поле значения в бланке свойств, вы можете изменить это значение (в рамках допустимого для этого типа данных). Большинство значений принимается системой по умолчанию, многие свойства можно изменить самостоятельно. Некоторые значения можно выбрать из раскрывающегося списка.

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

· для текстового и числового поля надо указать размер поля, причем для текста это допустимая длина значения (например, 20 или 40символов), а для числа – формат представления в компьютере (байт, целое (два байта), длинное целое и т.д.);

· для поля Дата/время
обязательно надо указать формат, чтобы система знала, как обрабатывать вводимые данные. Например, если выбрать Краткий формат даты, система будет ожидать от вас ввода именно даты (в русской версии – ДД.ММ.ГГГГ), а если выбрать Краткий формат времени, в этом поле придется набирать ЧЧ:ММ (часы и минуты);

· в качестве значения свойства Условие на значение вы можете указать логическое выражение, которое должно принимать значение True («Истина») при вводе данных в это поле. В следующем свойстве можно записать произвольное сообщение об ошибке, которое будет выдано системой, например: «Это значение поля недопустимо». Всвойстве Обязательное поле можно указать «Да» (пустые значения недопускаются) или «Нет» (пустые значения допускаются);

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

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

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

Действуя аналогично, введите следующие данные о других полях таблицы (табл. 2).

Завершив ввод описания полей таблицы, определите первичный ключ. Для этого, указав поле № личного дела
, щелкните кнопку «Ключевое поле» в панели инструментов Стандартная.

Таблица 2. Данные о полях таблицы

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

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

Операции с данными в таблице

Ввод данных
. Выбрав в окне таблицу Учащиеся, щелкните кнопку «Открыть». Установите курсор в поле № личного дела
и введите значение номер, например, П-69. По окончании ввода значения поля нажмите клавишу Tab
для перехода к следующему полю. В остальные поля этой записи введите остальные данные в первой записи.