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

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

В современном мире нужны инструменты, которые бы позволяли хранить, систематизировать и обрабатывать большие объемы информации, с которыми сложно работать в Excel или Word. Подобные хранилища используются для разработки информационных сайтов, интернет-магазинов и бухгалтерских дополнений. Основными средствами, реализующими данный подход, являются MS SQL и MySQL. Продукт от Microsoft Office представляет собой упрощенную версию в функциональном плане и более понятную для неопытных пользователей. Давайте рассмотрим пошагово создание базы данных в Access 2007.

Описание MS Access

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

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

Определения основных понятий

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

1. Предметная область – множество созданных таблиц в базе данных, которые связаны между собой с помощью первичных и вторичных ключей.
2. Сущность – отдельная таблица базы данных.
3. Атрибут – заголовок отдельного столбца в таблице.
4. Кортеж – это строка, принимающая значение всех атрибутов.
5. Первичный ключ – это уникальное значение (id), которое присваивается каждому кортежу.
6. Вторичный ключ таблицы «Б» – это уникальное значение таблицы «А», использующееся в таблице «Б».
7. SQL запрос – это специальное выражение, выполняющее определенное действие с базой данных: добавление, редактирование, удаление полей, создание выборок.

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

Создание БД

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

Итак, выполните следующее:

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

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

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

Совет! Для тонкой настройки формата данных перейдите на ленте во вкладку «Режим таблицы» и обратите внимание на блок «Форматирование и тип данных». Там можно кастомизировать формат отображаемых данных.

Создание и редактирование схем данных

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

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

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

Выполнение запросов

Что же делать, если нам нужны студенты, которые учатся только в Москве? Да, в нашей БД только 6 человек, но что, если их будет 6000? Без дополнительных инструментов узнать это будет сложно.

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

Виды запросов

SQL синтаксис реализует принцип CRUD (сокр. от англ. create, read, update, delete - «создать, прочесть, обновить, удалить»). Т.е. с помощью запросов вы сможете реализовать все эти функции.

На выборку

В этом случае в ход вступает принцип «прочесть». Например, нам нужно найти всех студентов, которые учатся в Харькове. Для этого нужно:

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

SELECT * FROM Студенты WHERE Адрес = «Харьков» AND Стипендия > 1000;

а результирующая таблица примет следующий вид:

На создание сущности

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

1. Перейти во вкладку «Создание».
2. Нажать кнопку «Конструктор запросов» в блоке «Другие».
3. В новом окне нажмите на кнопку SQL, после чего в текстовое поле введите команду:

CREATE TABLE Преподаватели
(КодПреподавателя INT PRIMARY KEY,
Фамилия CHAR(20),
Имя CHAR (15),
Отчество CHAR (15),
Пол CHAR (1),
Дата_рождения DATE,
Основной_предмет CHAR (200));

где «CREATE TABLE» означает создание таблицы «Преподаватели», а «CHAR», «DATE» и «INT» - типы данных для соответствующих значений.

Внимание! В конце каждого запроса должен стоять символ «;». Без него выполнение скрипта приведет к ошибке.

На добавление, удаление, редактирование

Здесь все гораздо проще. Снова перейдите в поле для создания запроса и введите следующие команды:

Создание формы

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

Все базовые функции MS Access 2007 мы уже рассмотрели. Остался последний важный компонент – формирование отчета.

Формирование отчета

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

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

1. Перейдите во вкладку «Создание».
2. Нажмите на кнопку «Мастер отчетов» в блоке «Отчеты».
   
   
3. Выберите интересующую таблицу и поля, нужные для печати.
   
   
4. Добавьте необходимый уровень группировки.
   
   
5. Выберите тип сортировки каждого из полей.

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

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

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

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

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

Рис. 2.5. Схема организации программного и информационного обеспечения

С использованием субд

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

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

На самом деле на этапе компиляции происходит слияние ядра базы данных и приложения (рис. 2.6).

Рис. 2.6. Схема слияния ядра БД и приложений

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

Элементы базы данных

База данных является системой, т.е. она состоит из некоторого числа элементов и отношений между ними (рис. 2.7)

Рис. 2.7. Структурные единицы БД

Наименьшим из них является элемент данных, который в ряде случаев называют также полем или атрибутом и который соответ­ствует одному реквизиту. Итак, элемент данных - это наименьшая семантически значимая поименованная единица данных. Элемент данных определяется следующими характеристиками: именем (Ф.И.О., дата рождения, наименование предприятия), типом (сим­вольный, числовой, календарный), длиной (максимально возмож­ное количество символов - 15 байт) и точностью (количество знаков после запятой для числовых данных).

Элементы данных организуются в записи, называемые корте­жами. Запись в общем случае соответствует показателю и несет данные об одном из однородных объектов, например одном счете, одном работнике и т.п. В ряде случаев применяют понятие агрега­та данных, которое занимает промежуточное положение между элементом данных и записью. Агрегат данных может быть простым (состоящим только из элементов данных) и составным (состоящим из элементов и простых агрегатов данных).

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

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

Значение приведенных терминов можно пояснить на схеме (рис. 2.8).

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

Рис. 2.8. Пример взаимосвязи структурных единиц БД

Жизненный цикл баз данных

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

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

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

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

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

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

Проектирование баз данных

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

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

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

Существует множество подходов к построению концептуальной модели данных: графовые модели, семантические сети, модель «сущность-связь» и т.д. Наиболее популярной из них является модель «сущность-связь» (ER -модель, от англ. Entity - Relation ). ER -модель была предложена американским ученым Питером Пин Шен Ченом в 1976 г. К настоящему времени разработано несколь­ко ее разновидностей, но все они базируются на графических диаграммах, предложенных Ченом.

Модель «сущность-связь» изображается графически в форме ER -диаграммы, которая состоит из набора множеств значений, описывающих свойства сущности и связи (Entity - Relationship Diagrams ).

К достоинствам этой модели относятся:

легкость формализации,

простота понимания;

описание графическими средствами;

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

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

Основными компонентами модели «сущность-связь» являют­ся сущность, атрибуты и связи (рис. 2.9).

Рис. 2.9. ER -диаграмма

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

Связь (Relationship ) - поименованная ассоциация между двумя сущностями, значимая для рассматриваемой предметной области.

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

Концептуальная модель составляется на основе интервью и опросов экспертов - специалистов в предметной области и долж­на удовлетворять ряду требований:

должна быть независима от конкретной СУБД;

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

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

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

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

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

В настоящее время известны три логические модели данных (их еще называют классическими или замечательными моделями), а именно иерархическая, сетевая и реляционная.

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

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

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

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

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

на этапе концептуального проектирования широко применя­ются графические методы;

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

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

Типы логических моделей данных

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

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

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

Основные достоинства иерархической модели - простота опи­сания иерархических структур реального мира и быстрое выпол­нение запросов, соответствующих структуре данных. Однако такие модели часто содержат избыточные данные и плохо приспособле­ны для представления взаимосвязей типа «многие ко многим». Кроме того, не всегда удобно каждый раз начинать поиск нужных данных с корня, а другого способа перемещения по базе в иерар­хических структурах не имеется. Иерархические системы - ста­рейшее поколение систем баз данных, они разрабатывались для больших ЭВМ.

Рис. 2.10. Иерархическая структура модели БД

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

Рис. 2.11. Сетевая структура модели БД

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

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

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

Основные понятия реляционных баз данных

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

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

Поясним перечисленные выше понятия на примере реляцион­ной модели БД, содержащей сведения о сотрудниках некоторой фирмы. Рассмотрим таблицу с данными о сотрудниках фирмы (табл. 2.6).

Таблица 2.6

Сотрудники

Табельный номер	Фамилия И.О.	Код отдела	Рабочий телефон
	ПЕТРОВ А.В.
	РОМАНЕНКО С.Т.
	СТЕПАНОВА И.С.

Можно увидеть, что у всех трех записей атрибуты одинаковы, однако принимают разные значения. Так, для записи № 1 атрибут «табельный номер» принимает значение 008976, а для записи № 2 - 008980 и т.д. Значения некоторых атрибутов у разных запи­сей могут совпадать, например у записей № 1 и № 2 одинаковое значение атрибута «код отдела». Однако в каждой таблице должен быть атрибут (или совокупность атрибутов), значение которого никогда не повторяется и однозначно идентифицирует каждую строку таблицы. Это нужно для того, чтобы при работе с базой можно было отличать одну запись от другой. Такие атрибуты на­зывают уникальными. Уникальный атрибут таблицы или совокуп­ность ее уникальных атрибутов называют первичным ключом или ключевым полем. В данной таблице ключом является атрибут «та­бельный номер».

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

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

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

Таблица 2.7

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

РОМАНЕНКО С.Т.

ОТДЕЛ КАДРОВ

Можно увидеть, что отношения между двумя таблицами устанавливаются на основе соответствия значений атрибутов двух таблиц, в нашем случае это атрибут "код отдела" таблицы "СОТРУДНИКИ" и атрибут "код" таблицы "ОТДЕЛЫ". Такие атрибуты называют атрибутами связи. Атрибут связи в одной таблице должен быть ключом. В приведенном примере атрибут "код" является ключом для таблицы "ОТДЕЛЫ" Если бы это было не так и коды отделов в этой таблице повторялись, невозможно было бы определить, о каком из отделов говорится в первой таблице. Второй атрибут связи – в данном случае "код отдела" таблицы "СОТРУДНИКИ" – называют внешним ключом , так как он ссылается на ключ другой (внешней) таблицы (рис. 2.12).

Первичный ключ таблицы 2

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

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

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

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

СЧЕТА-ФАКТУРЫ СТРОКИ

СЧЕТОВ-ФАКТУР

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

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

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

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

Хранилище данных

Хранилище данных - это система, предназначенная для обес­печения единого информационного пространства с целью анализа и оптимизации его бизнеса.

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

обеспечение повседневной работы пред­приятия по вводу и обработке информации;

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

Задачи первого класса - автоматизация оперативной деятельности - пол­ностью решаются О LT Р -системами (Online Transactional Process ­ ing - оперативная обработка трансакции), к которым относятся автоматизированные банковские системы, учетные системы и др. Для работы с аналитическими данными предназначены OLAP - системы (Online Analytical Processing - оперативная аналитическая обработка), которые построены по технологии хранилища данных и предназначены для агрегированного анализа больших объемов данных. Эти системы являются составной частью систем принятия решений или управленческих систем класса middle и top manage ­ ment , т.е. систем, предназначенных для пользователей среднего и высшего уровней управления компанией.

Сравнительные характеристики использования данных в сис­темах операционной и аналитической обработки приведены в табл. 2.8.

Таблица 2.8

Характеристики операционных и аналитических информационных систем

Свойства данных	Система
	операционной обработки	аналитической обработки
Назначение	Оперативный поиск, несложные виды обработки	Аналитическая обработка, прогнозирование, моделирова­ние
Уровень агрегации	Детализированные данные	Агрегированные данные
Время хранения	От нескольких месяцев до одного года	От нескольких десятков лет и более
Частота обновления	Высокая. Обновление малыми порциями	Низкая. Обновление большими порциями, до нескольких миллионов записей за один раз
Критерий эффективно­сти	Количество трансакций в единицу времени	Скорость выполнения сложных запросов и прозрачность струк­туры хранения для пользовате­лей

Таким образом, современная ЭИС представляет собой систему, основанную на совместном использовании трансакционных OLTP - систем и хранилищ данных (Data Warehouse ).

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

Отличительными чертами хранилища данных являются:

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

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

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

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

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

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

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

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

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

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

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

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

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

Аппарат выполнения расчетов. Специальный аппарат выполне­ния расчетов обеспечивает:

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

консолидацию данных - суммирование данных по организа­ционной иерархии, например вычисление сводного баланса банка;

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

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

Интерфейсы для внешних систем. Хранилище данных предостав­ляет информацию внешним аналитическим системам и генерато­рам отчетов. Для этого применяются промышленные стандарты доступа к данным.

Архитектура системы управления хранилищем данных показа­на на рис. 2.15.

Рис. 2.15. Архитектура системы управления хранилищем данных

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

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

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

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

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

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

Таким образом, многомерную модель ХД целесообразно ис­пользовать, когда ее объем невелик (не более 10-20 гигабайт), а гиперкуб имеет стабильный во времени набор измерений.

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

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

Рис. 2.16. Логическая схема комбинированного хранилища данных

Витрины данных

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

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

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

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

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

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

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

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

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

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

Рис. 2.17. Взаимосвязь витрин данных и хранилища данных

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

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

Данные, попав в хранилище, могут быть распространены среди многих витрин данных для доступа пользовательских запросов. Эти витрины данных могут принимать различные формы - от баз данных «клиент-сервер» до баз данных на рабочем столе, OLAP - кубов или даже динамических электронных таблиц. Выбор инстру­ментов для пользовательских запросов может быть широким и отображать предпочтения и опыт конкретных пользователей. Ши­рокий выбор таких инструментов и простота их применения сде­лают их внедрение наиболее дешевой частью реализации проекта хранилища данных. Если данные в хранилище имеют хорошую структуру и проверенное качество, то их передача в другие витрины данных станет рутинной и дешевой операцией.

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

• Перевод

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


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

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

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

Фото: binaryape

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

* серверы БД;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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