Лучшие системы управления базами данных для малого бизнеса. Организация баз данных в информационных технологиях

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

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

1. Понятие СУБД.

2. Реляционные базы данных.

3. Виды баз данных.

4. Виды структур баз

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

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

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

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

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

Реляционные базы данных.

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

Начнем с реляционной модели. В далеком 1969 году американский математик доктор Э.Ф. Кодд (Е.F. Codd) проанализировал сложившуюся к тому времени ситуацию по базам данных и пришел к выводу, что дело плохо. Во всех имевшихся в то время моделях были существенные недостатки: избыточность данных, сложность обработки и отсутствие безопасности хранения информации и т.п. После тягостных раздумий Кодд решил создать свою модель - реляционную. Для тех, кто злостно прогуливал английский, напомню, что relation переводится как "отношение" или просто "таблица". Гениальный доктор просто реализовал хранение данных в табличной форме, то есть организовал такие "хранилища" в виде логических структур (физические методы хранения могут быть любыми). Тем самым Кодд сумел добиться наглядности представления информации и удобства ее обработки. Благодаря достижению этого гения для формирования таблицы данных стало достаточно выполнить определенный логический запрос, подчиняющийся законам булевой алгебры. Среди операторов манипуляции данными существуют минимум три операции: извлечение строк (SELECT), извлечение столбцов (PROJECT) и объединение таблиц (JOIN). В результате этих действий мы получаем таблицу. И простой вывод из всего этого: результатом любой операции в реляционной модели является объект того же рода, что и объект, над которым осуществлялось действие.

Это и есть основное свойство описываемой модели.

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

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

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

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

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

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

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

В теории СУБД выделяется три вида связей: один-к-одному, один-ко-мно-гим и многие-ко-многим. Расскажу подробно о каждом виде.

1. Один -к-одному. Этот вид связи применяется в том случае, когда первичный ключ одной таблицы ссылается на ключ другой. Чтобы было понятнее, приведу пример: допустим, у нас имеется три таблицы хакерской БД. Первая – информация о хакере: дата рождения, пол (девушки тоже бывают взломщиками;)) и ICQ. Вторая – хакер-ские течения (тип течения, его сложность и начальные капиталовложения). Ну и третья – тип выхода в интернет (технология, скорость доступа, оценка безопасности). Все эти таблицы нельзя свести в одну, так как в результате отсутствия связи между данными о доступе в интернет и о хакерс-ких течениях (и не только о них) мы получим путаницу. А при реализации связи в виде трех разных таблиц (с помощью первичного ключа - порядкового номера) обеспечивается и высокая скорость обработки, и упорядоченность данных.

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

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

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

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

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

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

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

Основные языки обращений к БД все же основываются на простом SQL-синтаксисе и имеют своего рода расширение, применимое к объектам. Примерами таких языков служат ORION, Iris и O2 Reloop.

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

Для нужд обычного человека (то есть тебя) вполне хватит реляционных СУБД, которые применяются повсеместно. Это и всенародно любимый MySQL, и менее любимый Access, и MSSQL. Подобных систем управления масса, определись и выбери ту, что тебе больше по сердцу. А сделать этот нелегкий выбор, как всегда, поможет этот уникальный СПЕЦвыпуск;).

Типы баз данных.

Какие бывают базы данных? В большинстве случаев решения программистов ограничиваются двумя типами: локальная и клиент-серверная. В первом случае получается шампунь "все-в-одном". Во втором мы разделяем данные и клиентское приложение и получаем два уровня.

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

ЛОКАЛЬНАЯ БАЗА

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

Яркими и наиболее распространенными представителями такого рода баз являются Dbase (файлы с расширением.dbf), Paradox (расширение.db) и Access (расширение.mdb). Форматы Dbase и Paradox - это даже не базы данных, а таблицы, потому что в одном файле может храниться только одна таблица данных. Индексы, ускоряющие поиск и осуществляющие сортировку, находятся в отдельных файлах. Таким образом, одна база данных может состоять из множества файлов, и это иногда приводит к определенным проблемам при поставке приложения конечному пользователю.

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

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

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

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

СЕТЕВАЯ БАЗА ДАННЫХ

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

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

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

Я бы побил того, кто придумал такую технологию, потому что это самое настоящее издевательство над системой. Представляешь, что будет, если надо выполнить запрос на базе данных в 1 Гб с телефонным соединением в 34 Кб/с? Это то же самое, что заставить

добывать нефть через трубочку для молочных коктейлей.

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

Но страшнее всего начали вести себя индексы. У таблиц Paradox, если они находились на расшаренном диске Win95, мне приходилось ремонтировать индексы как минимум раз в неделю. Когда я убрал файлы базы данных на сетевой диск сервера NetWare 3.11 (это был где-то 1998 год), проблемы с нарушением индексации сразу исчезли (наверное, потому что это действительно сервер, а не корявый Windows 9x).

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

КЛИЕНТ-СЕРВЕР

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

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

FROM Имя таблицы

WHERE Колонка LIKE ‘А%’

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

Получив нужные данные, сервер возвращает только их и ничего больше. Таким образом, клиент в любой момент может запросить у сервера нужные данные и не будет необходимости гонять по сети всю базу данных. При хорошо построенном приложении и оптимальных запросах клиент сможет работать с базой данных любого размера даже через модем в 56 Кбит/с. Неплохо? Главное - запрашивать только то, что нужно, и маленькими кусками.

ОСОБЕННОСТИ КЛИЕНТ-СЕРВЕРА

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

В более солидных клиент-серверных базах (MS SQL Server, Oracle и т.д.)

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

1. вьюшки – более подробно обсуДим в статье по безопасности;

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

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

хранимые процедуры и функции, которые выполняются на сервере по мизерному запросу клиента и могут содержать целые подпрограммы с логикой, которые будут выполнять какие-либо действия; для написания таких программ используется уже не просто язык SQL, а его расширение – Transact-SQL (для MS баз) и PL/SQL (для Oracle и др.).

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

ИНДЕКСЫ НА СЕРВЕРЕ

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

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

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

В случае с серверной базой индексы чаще всего (в зависимости от базы и типа индекса) хранятся немного подругому – в виде дерева. Сколько слов надо проверить для поиска слова "якорь" в базе данных при линейном индексе? По сути, практически все. При древовидном хранении индекса - не более чем для слова "Абажур". Для пояснения древообразного индекса рассмотрим классическую задачу (в реальности все немного сложнее, но идея такая же). В самом верху дерева хранится алфавит. Программа находит букву А и спускается на уровень ниже. Здесь она находит все слова на буквы А, Б и двигается еще ниже. И так - пока не найдется нужное слово

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

ТРЕТИЙ УРОВЕНЬ

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

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

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

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

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

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

Виды структур баз

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

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

Структура Microsoft Access

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

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

Связь с другими программами и внешними базами данных

Как уже понятно, Access - это программа, позволяющая не только использовать собственные данные, вводимые пользователем, но и связывать их между собой. Возможности приложения таковы, что информация может быть импортирована из других приложений (FoxPro, Paradox, Excel, Word и др.). Для упрощения процедур данные можно не импортировать, а связать, причем не только с указанными программами, а и с источниками в сетевом окружении или в интернете.

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

Создание на основе шаблонов

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

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

База данных с нуля

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

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

Нюансы импорта и связывания данных с другими источниками

Что касается импорта данных, здесь возможности у программы практически не ограничены. Главным условием является только то, что импортируемые данные должны быть разбиты по типу табличных (как таблицы в Excel или Word). Если же импорт производится, например, в текстовом варианте из «Блокнота», создать подобную структуру можно при помощи табулятора (клавиша Tab).

Можно использовать списки SharePoint, а также связывать данные для упрощения работы. Для этого применяется специальная команда на вкладке внешних данных, расположенной в группе импорта и связывания. Здесь предлагаются уже готовые решения (Excel, Word и т. д.). При выборе останется только указать расположение нужного файла, место сохранения в текущей базе данных и подтвердить выбор.

Заключение

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

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

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

Назначение Microsoft Access

1. Создание СУБД для одноранговых локальных сетей.
2. Проектирование базовых объектов для двумерных таблиц с несколькими типами данных.
3. Установка связи, поддержка целостности данных, удаления записей и каскадного обновления.
4. Хранение, ввод, сортировка, просмотр, изменение и выборка сведений из проектов, используя разные средства контроля информации и аппараты логической алгебры.
5. Проведение различных операций над целыми группами записей.

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

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

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

Угол экрана компьютера, на котором показан список поставщиков в базе данных Microsoft Access (изображение).

Классические базы данных - лишь одна из возможностей

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

Шаблоны приложений

Быстро начните работу, создав персонализированное приложение либо используя набор новых и профессионально разработанных шаблонов приложений.

Шаблоны таблиц

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

Возможности приложений

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

Управление связанными элементами

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

Управление автозаполнением

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

Приложения для развертывания SharePoint

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

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

Access: что это такое?

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

Access: основные направления использования приложения

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

Microsoft Access: структура

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

1. Таблица – это элемент, в котором хранится основная информация в определенном формате (текстовый, числовой, графический);
2. Запрос – это средство обращения к связанным элементам, другим базам данных или сторонним программам;
3. Форма – это предоставление данных или информации в удобном для пользователя виде;
4. Отчет – это вывод обработанных результатов;
5. Макрос – это исполняемый элемент, который позволяет при возникновении какого-то события выполнять определенные действия, формирование отчета, создание запроса;
6. Модуль – представляет собой средство языка Visual Basic, которое позволяет существенно расширить возможности программы на основе использования многочисленных функций и создания процедур;

Microsoft Access: связь с внешними базами данных и другими программами

Как уже должно быть понятно, Microsoft Access позволяет не только использовать собственные данные, вводимые пользователем, но и связывать их между собой. Возможности программы таковы, что информация может быть импортирована из различных приложений , например, Paradox, FoxPro, Excel, Word итак далее. Данные для упрощения процедур можно не импортировать, а связывать, причем не только с данными программами, но и с источниками в интернете или сетевом окружении. Сам процесс связывания осуществляется на базе запросов по типу того, как работают базы данных SQL. Кстати программа Access их тоже поддерживает.

Как создать базы данных на основе шаблонов?

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

Как создать базу данных с нуля?

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

Особенности импорта и связывания данных с другими источниками

Если говорить об импорте данных, то здесь программа Microsoft Access имеет практически неограниченные возможности. Главное условие заключается в том, что импортируемые данные должны быть разбиты по типу табличных, как это делается в Wordили Excel. Если импорт осуществляется, например, в текстовом варианте программы «Блокнот», то для создания подобной структуры можно использовать клавишу «Tab»(табулятор). Также имеется возможность использования списков Share Point и связывания данных для упрощения работы. Для этой цели на вкладке внешних данных, которая расположена в группе связывания и импорта, применяется специальная команда. Тут также предлагаются и уже готовые решения (Word, Excel итак далее). В случае выбора останется указать только расположение необходимого файла , место хранения в текущей базе данных, а затем подтвердить сделанный выбор.

Послесловие

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

Введение

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

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

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

1. Организация баз данных

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

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

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

Схемы и подсхемы базы данных часто изображают в виде диаграмм. На рис. 1 приведена общая схема логической структуры базы данных и подсхемы двух прикладных программистов, которые имеют различные представления о данных. Сплошные линии обозначают связи на схеме. Простые связи обозначаются одной стрелкой, связи "один ко многим" - двойной стрелкой. Штриховые линии отображают перекрестные ссылки. Наличие перекрестных ссылок позволяет избежать повторения записей ПОСТАВЩИК и СПЕЦИФИКАЦИИ - ПАРТИИ -ТОВАРА в каждой записи СТАТЬЯ ЗАКУПКИ.

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

2. Системы управления базами данных

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

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

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

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

Для работы с системой управления базой данных необходимо несколько языков: языки программирования, языки описания схем и подсхем, языки описания физических данных. Прикладной программист использует языки программирования для написания программ (КОБОЛ, ФОРТРАН, ПЛ/1, АССЕМБЛЕР) и средства для описания данных - язык описания подсхем. Язык описания подсхем может представлять собой средство описания данных в языке программирования, средство, обеспечиваемое СУБД, а также независимый язык описания данных. Многие СУБД используют средства описания данных языков программирования. Для прикладного программиста СУБД должна обеспечить средства передачи команд и интерпретации сообщений, выдаваемых системой. Интерфейс между прикладной программой и СУБД - язык манипулирования данными - встраивается в язык программирования. Запись запрашивается на языке манипулирования данными и считывается в рабочую область прикладной программы; аналогично при включении записи в базу данных прикладная программа помещает ее в рабочую область и выдает команду на языке манипулирования данными. Типичными командами языка манипулирования данными являются: открыть файл или набор записей; закрыть файл или набор записей; определить местонахождение и считать указанный экземпляр записи; передать содержимое указанных элементов данных из определенного экземпляра записи; заменить значение определенных элементов указанного экземпляра записи величинами из рабочей области программы; вставить в набор записей запись из рабочей области; удалить определенный экземпляр записи из последовательности записей; запомнить новый экземпляр записи в базе данных; удалить определенный экземпляр записи из базы данных; переупорядочить записи в группе в убывающей или возрастающей последовательности по указанному ключу.

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

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

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

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

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

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

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

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

3. Выбор СУБД

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

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

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

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

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

Ниже приведены краткие характеристики некоторых универсальных СУБД.

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

В системе допускается обращение к данным из прикладных программ пользователя, написанных на языке АССЕМБЛЕР, ПЛ/1, КОБОЛ, АЛГОЛ-60, ФОРТРАН-4.

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

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

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

Пользовательские программы могут быть написаны на языках КОБОЛ, ФОРТРАН, БЕЙСИК-2 и обращаются к базе данных с помощью САМ-интерфейса.

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

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

Языком манипулирования данными является язык КВАНТ СКРИПТ-М. Это англоподобный диалоговый язык, предназначенный для эффективного поиска и выделения записей в базе данных и вывода их на дисплей.

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

4. Специализированные базы данных

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

5. Распределенные базы данных

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

Основной проблемой при создании РБД является размещение данных; это определяет такие характеристики РБД, как объемы хранимых и обновляемых данных, интенсивность потоков информации и надежность систем.

Проектирование РБД может проходить в условиях:

а) создание АСУ только начинается и стоит задача выбора оптимальной структуры РБД и размещения отдельных ЛБД;

б) существует определенное количество ЛБД и ВЦ и стоит задача размещения дополнительного числа ЛБД и оптимального изменения структуры связей в системе;

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

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

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

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

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

1) по структурной информации о размещении данных в РБД происходит поиск необходимой ЛБД и обращение к этой ЛБД;

2) осуществляется поиск в ЛБД более высокого ранга; если необходимая информация отсутствует, анализируется структурная информация о содержании всех подчиненных ЛБД; если необходимая информация отсутствует, переходят к ЛБД более высокого уровня иерархии;

3) осуществляется обращение в управляющую ЛБД, где хранится структурная информация о всех ЛБД;

4) осуществляется опрос всех ЛБД либо параллельно, либо последовательно.

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

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

Стратегия 3 минимизирует структурную информацию.

Стратегия 4 отличается большими потоками запросной информации.

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

Существует несколько способов совместного использования базы данных 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 для управления доступом и изменения структуры. Позволяет использовать некоторые объекты базы данных, например формы, на основе браузера.	Гибкий способ. Можно легко разрабатывать новые функции базы данных без нарушения работы. Пользователи могут изменять структуру объектов в собственной копии.