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

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

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

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

Базы данных работают под управлением систем управления базами данных (СУБД), которые определяются как совокупность языков и программ, необходимых для работы с базой данных. СУБД позволяют создавать базы данных, вносить и изменять ин­формацию в них, осуществлять доступ к этой информации. Схема организации программного и информационного обеспечения в случае использовании СУБД будет принципиально иной (рис. 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 - кубов или даже динамических электронных таблиц. Выбор инстру­ментов для пользовательских запросов может быть широким и отображать предпочтения и опыт конкретных пользователей. Ши­рокий выбор таких инструментов и простота их применения сде­лают их внедрение наиболее дешевой частью реализации проекта хранилища данных. Если данные в хранилище имеют хорошую структуру и проверенное качество, то их передача в другие витрины данных станет рутинной и дешевой операцией.

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

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

Структура Microsoft Access

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Заключение

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Послесловие

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

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

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

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

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

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

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

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

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

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

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

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

* серверы БД;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пример

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

FROM Имя таблицы

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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