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

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

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

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

Filemaker Pro 12

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

Microsoft Access 2010

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Цели использования баз данных

Использование БД в основном обеспечивает:

1. независимость данных и программ;

2. реализацию отношений между данными;

3. совместимость компонентов БД;

4. простоту изменения логической и физической структур БД;

5. целостность, восстановление и защиту БД и др.

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

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

Независимость данных и программ объясняется двумя основными причинами.

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

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

Отношения между данными . Данные об объектах в БД связаны между собой отношениями (связями). Отношение между объектами А и В обозначим следующим образом:

где F(х) - вид связи объекта А с объектом В; G(х) - вид связи объекта В с объектом А. Функции F(х) и G(х) могут принимать значения U и N - единичная и множественная связи соответственно. Обычно рассматривают четыре типа отношений.

1. Отношение

(один к одному) означает, что каждому экземпляру объ­екта А В и, наоборот, любому экземпляру объекта В может соответствовать только один экземпляр объекта А. Например:

ПРЕДПРИЯТИЕ -- ДИРЕКТОР

2. Отношение

A -- B (1: N )

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

ОРГАНИЗАЦИЯ -- ПОДРАЗДЕЛЕНИЕ (1:N)

3. Отношение

A -- B (1:N )

(многие к одному) означает, что каждому экземпляру объекта А может соответствовать только один экземпляр объекта В и среди экземпляров объекта В могут быть такие, которым соответствует несколько экземпляров объекта А. Очевидно, что если 1: N - тип отношения между А и В, то N : 1 - тип отношения между В и A . Например:

РАБОЧИЙ -- ПРЕДПРИЯТИЕ

4. Отношение

A -- B (M: N )

(многие ко многим, или групповое) означает, что может существовать экземпляр объекта А, которому соответст­вует несколько экземпляров объекта В, и, наоборот, од­ному экземпляру объекта В может соответствовать не­сколько экземпляров объекта А. Очевидно, что если М: N А и В, то N:М - тип отношения между объектами В и А. Например:

ПОСТАВЩИК -- ПРОДУКТ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание MS Access

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

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

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

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

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

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

Создание БД

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

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


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

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

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



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

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

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

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


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


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

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

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

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

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

На выборку

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


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

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

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

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

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

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

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

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


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

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

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


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

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


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

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

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

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

  1. Перейдите во вкладку «Создание».
  2. Нажмите на кнопку «Мастер отчетов» в блоке «Отчеты».

  3. Выберите интересующую таблицу и поля, нужные для печати.

  4. Добавьте необходимый уровень группировки.

  5. Выберите тип сортировки каждого из полей.
mob_info