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

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

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

Если вы владелец малого бизнеса, и в своей работе еще не используете Систему управления взаимоотношениями с клиентами (CRM или Customer Relationship Management), автоматизирующую генерацию стратегий взаимодействия с клиентами, то успех вашего дела подвержен определённым рискам. Помните, что ваши конкуренты не дремлют!

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

Filemaker Pro 12

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

Microsoft Access 2010

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

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

Oracle Application Express (APEX) база данный бизнес

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Выделяют следующие виды СУБД:

* полнофункциональные СУБД;

* серверы БД;

* средства разработки программ работы с БД.

Полнофункциональные СУБД представляют собой традиционные СУБД. К ним относятся dBaseIV, Microsoft Access, Microsoft FoxPro и др.

Серверы БД предназначены для организации центров обработки данных в сетях ЭВМ. Серверы БД обеспечивают обработку запросов клиентских программ обычно с помощью операторов SQL. Примерами серверов БД являются: Microsoft SQL Server, InterBase и др.

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

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

* клиентских программ;

* серверов БД и их отдельных компонентов;

* пользовательских приложений.

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

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

* возможность организации совместной параллельной работы многих пользователей;

* масштабируемость;

* переносимость на различные аппаратные и программные платформы;

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

* обеспечение безопасности хранимых данных и развитой структурированной системы доступа к ним.

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

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

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

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

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

· язык описания данных -- высокоуровневый непроцедурный языкструктуры данных;

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

Названные языки в различных СУБД могут иметь отличия. Наибольшее распространение получили два стандартизованных языка: QBE -- язык запросов по образцу и SQL -- структурированный язык запросов. QBE в основном обладает свойствами языка манипулирования данными, SQL сочетает в себе свойства языков обоих типов.

СУБД реализует следующие основные функции низкого уровня:

* управление данными во внешней памяти;

* управление буферами оперативной памяти;

* управление транзакциями;

* ведение журнала изменений в БД;

* обеспечение целостности и безопасности БД.

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

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

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

Транзакции присущи три основных свойства:

* атомарность (выполняются все входящие в транзакцию операции или ни одна);

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.24.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.25.

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 3.1

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

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

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

Рис. 3.26.

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

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

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

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

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

Рис. 3.27.

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

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

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

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

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

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

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

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

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

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

Рис. 3.28.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис. 3.29.

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

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

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

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

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

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

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

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

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

Рис. 3.30.

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

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

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

Рис. 3.31.

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

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

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

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

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

Структура базы данных

Система базы данных состоит из следующих элементов:

Таблицы: Данные хранятся в строках (записи) и столбцах (поля).

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

Запросы: Запросы написаны для извлечения строк и / или столбцов на основе заранее определенного состояния.

Наиболее известные базы данных это: MySQL, SAP, Oracle, IBM DB2 и т.д. СУБД или "система управления базы данных» используется в качестве интерфейса для связи между пользователем и базой данных.

Что такое базы данных и для где они используются?

Хранение данных / Вставка: Начальная фаза (перед вводом данных) включает в себя создание структуры данных, таких как таблицы (с необходимым количеством строк и столбцов). Затем данные вносят в эту структуру.

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

Данные модификации / Updation: Статические данные не нуждаются в обновлении. Тем не менее, динамические данные нуждаются в постоянной модификации. Рассмотрим возраст сотрудников в организации. Она должна обновляться каждый год (периодическое обновление).

Пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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