База данных – основа информационного обеспечения
управленческой деятельности*
Будучи основным фундаментальным средством построения информационных систем, используемых в производстве, бизнесе и научной деятельности, базы данных и системы управления ими составляют обширную область исследований.
По организации и технологии обработки информации базы данных подразделяются на централизованные и распределенные.
Централизованная база данных разрабатывается и функционирует на принципах централизации в одном месте, на одном компьютере, в виде одного информационного массива. Такая база данных применяется в локальных сетях персональных компьютеров для одновременного доступа нескольких пользователей со своих рабочих мест. База данных при этом размещается на машине-сервере.
Распределенная база данных представляет собой базы данных, которые физически распределены по взаимосвязанным ресурсам вычислительной сети и доступны для совместного применения в разных местах. Распределенная база данных разъединена только физически, но не логически. Вся база данных потенциально доступна для любого конечного пользователя, который работает с ней так же, как и с централизованной. Распределенные базы данных требуют высокого уровня развития национальных и международных систем связи между компьютерами.
По способу доступа к информации базы данных делятся на базы данных с локальным доступом и с удаленным (сетевым) доступом.
Системы централизованных баз данных с сетевым доступом организуются по двум архитектурам: файл-сервер и клиент-сервер.
Файл-сервер. Системы баз данных, построенные с помощью сетевых версий, иногда неправомерно называют распределенными базами данных, в то время как они фактически являются лишь распределенным (сетевым) доступом к централизованной базе данных.
Архитектура систем баз данных с сетевым доступом предполагает выделение одной машины в сети в качестве центральной, которая называется сервером файлов. Все другие машины сети выполняют функции рабочих станций, с помощью которых поддерживается доступ пользователей системы к централизованной базе данных. На рабочих станциях могут создаваться и локальные базы данных.
Поскольку концепция «файл-сервер» предполагает передачу файлов баз данных с файл-сервера для обработки на рабочих станциях, характеризующиеся большим сетевым трафиком, что отрицательно сказывается на производительности и надежности системы.
В последнее время происходит существенная трансформация подходов к использованию баз данных в обстановке локальных сетей, направленная на повышение роли центральной машины. Новая модель взаимодействия компьютеров в сети получила название «клиент-сервер».
Клиент-сервер. Сервер базы данных представляет собой мультипользовательскую версию системы управления базой данных, параллельно обрабатывающую запросы, поступающие со всех рабочих станций. По запросу клиента (рабочей станции) на сервере ищутся и выбираются необходимые данные, которые транспортируются по сети от сервера к рабочим станциям. Здесь основная обработка выполняется центральной машиной, что позволяет существенно уменьшить сетевой трафик, сократить время на ожидание блокированных ресурсов данных в мультипользовательском режиме, разгрузить рабочие станции и при достаточно мощной центральной машине использовать для них более дешевое оборудование. Для современных систем управления базами данных архитектура «клиент-сервер» стала фактически стандартом.
С ростом популярности систем управления базами данных появилось множество различных моделей данных. В зависимости от способа представления взаимосвязей между объектами логическая модель данных может быть иерархической, сетевой и реляционной.
Иерархическая модель данных. Взаимосвязи между объектами отражаются по принципу иерархии типов объекта в виде связанного графа, вершины которого размещены на различных уровнях иерархии. Самая высокая вершина называется корнем (родитель), а остальные, находящиеся на нижних уровнях иерархии, – подчиненными (потомки). Иерархическая модель данных обеспечивает взаимосвязь между главным и подчиненным объектами типа «один-ко-многим» (1:М), например, одному изделию соответствует несколько материалов, используемых на различных операциях обработки, сборки.
Основное внимание в ограничениях целостности в иерархической модели уделяется целостности ссылок между предками и потомками с учетом основного правила: никакой потомок не может существовать без родителя.
Рис. 2.5. Схема иерархической модели данных
Сетевая модель. В сетевой модели данных любой объект может быть и главным, и подчиненным; каждый объект может участвовать в любом количестве взаимосвязей. Данные представляются при помощи записей и связей. Запись (объект) в сетевой модели данных (в отличие от иерархической) может иметь множество как подчиненных ей записей, так и записей, которым она сама подчинена.
Недостатком сетевой модели данных является высокая сложность и жесткость базы данных, построенной на ее основе, а также сложность ее понимания обычным пользователем. Кроме того, в сетевой модели данных ослаблен контроль целостности связей из-за допустимости установления произвольных связей между записями.
Рис. 2.6. Общая схема сетевой модели данных
Реляционная модель. В реляционной модели данные представлены в виде двумерных таблиц. В этой модели объекты и взаимосвязи между ними представлены при помощи таблиц. Табличная структура данных отражает отношения между реальными объектами и их характеристиками. Поиск и обработка записей не зависят от организации хранения данных в памяти компьютера. При этом эффективно используется математическая логика и алгебра.
С помощью одной таблицы удобно описывать простейший вид связей между данными, а именно: деление одного объекта, информация о котором хранится в таблице, на множество подобъектов, каждому из которых соответствует строка или запись таблицы. К реляционным моделям относят, например, Paradox, FoxPro, Access.
Основными недостатками реляционной модели являются следующие: отсутствие стандартных средств идентификации отдельных записей и сложность описания иерархических и сетевых связей.
Рис. 2.7. Общая схема реляционной модели данных
В последние годы все большее признание и развитие получают объектно-ориентированные базы данных, в которых модель данных более близка сущностям реального мира. Объекты можно сохранить и использовать непосредственно, не раскладывая их по таблицам. Типы данных определяются разработчиком и не ограничены набором предопределенных типов. Существенной особенностью объектно-ориентированной базы данных можно назвать объединение объектно-ориентированного программирования с технологией баз данных для создания интегрированной среды разработки приложений.
Традиционными областями применения объектно-ориентированных баз данных являются системы автоматизированного проектирования, моделирование, мультимедиа, поскольку именно в данных областях всегда существовала потребность найти адекватное средство хранения больших объемов разнородных данных, переплетенных многими связями.
К объектно-ориентированным базам данных можно отнести систему управления базами данных ONTOS, ORACLE 8.O и т.д.
Однако большинство систем управления базами данных для персональных компьютеров работает с реляционной моделью данных.
2.5. Моделирование данных информационных систем:
Реляционная модель
Реляционная модель баз данных была предложена в 1969 г. сотрудником фирмы IBM Коддом. Модель основана на математической теории множеств и предикативной логике. Основная идея реляционной модели предполагает следующее. База данных состоит из ряда неупорядоченных таблиц, которыми можно манипулировать посредством непроцедурных операций, результатом выполнения которых также являются таблицы.
В реляционной модели таблицы используются для представления предметов или процессов реального мира. Каждая таблица служит для представления объектов только одного типа. Реальным объектом может быть заказчик, единица оборудования или счет-фактура. Таблицы могут содержать также информацию о событиях, например, заказах, визитах пациентов, выпуске продукции.
Таблицы состоят из строк и столбцов. Реляционная модель требует, чтобы каждая строка была уникальной. Если в таблице допускается дублирование строк, то продублированную строку будет невозможно однозначно идентифицировать программными средствами, что приведет к неопределенности.
Итак, база данных – это список (таблица) с информацией, состоящей из строк (называемых записями) и столбцов (называемых полями). База данных может быть, например, просто списком телефонных номеров клиентов, состоящим из двух столбцов: один – с названиями, другой – с телефонами и много строк, содержащих название и номера телефонов. Используя приведенную выше терминологию, можно сказать, что Клиент и Телефон являются полями, а каждая строка, содержащая имя и номер телефона, – записью. На рисунке 2.8 изображена простейшая база данных.
Рис. 2.8. База данных «Телефонный справочник клиентов»
Как видно из рисунка 2.8, для каждой строки телефонного справочника повторяются информация о городах и их кодах. Занесем всю информацию о городах в отдельную таблицу, которую назовем Города (табл. 2.1).
Таблица 2.1
Города
| Код города | Город |
| Москва | |
| Ростов-на-Дону |
Уникальность строк таблицы Города гарантирует первичный ключ – столбец (или группа столбцов), содержащих уникальные в рамках данной таблицы значения. В нашем примере первичным ключом будет поле Код города.
Каждая таблица может иметь только один первичный ключ, несмотря на то что уникальные значения могут присутствовать в нескольких столбцах или группах столбцов. Все столбцы (или группы столбцов) с уникальными значениями называются возможными ключами. Именно из них выбирается первичный ключ. Остальные столбцы возможных ключей называются альтернативными ключами. Ключи могут быть простыми, состоящими из одного столбца, или составными, состоящими из нескольких столбцов. Решение о том, какой из возможных ключей станет первичным, принимает разработчик – здесь нет твердых правил. Однако, удобнее всего в качестве первичных ключей использовать числовые первичные ключи, например, столбцы типа Счетчик (AutoNumber), особенно если нет подходящих возможных ключей. Это связано с тем, что, во-первых, имена или названия объектов иногда меняются, а во-вторых, применение столбцов с числовыми данными для поиска и сортировки данных более эффективно, чем столбцов с текстовой информацией.
Хотя первичные ключи являются свойством конкретных таблиц, необходимость в них отпадает, если базы данных состоят только из независимых несвязанных таблиц. Особое значение первичные ключи приобретают при создании связей, объединяющих множество таблиц в единое информационное пространство (базу данных).
Внешний ключ – это столбец одной таблицы, который ссылается на первичный ключ другой таблицы. В таблице 2.2 показано, как первичный ключ из таблицы Города добавлен в таблицу Телефонный справочник как внешний ключ для обеспечения связи между таблицами.
Таблица 2.2
Клиенты
| Клиент | Телефон | Код города |
| ООО Полет | 255-45-11 | |
| ЗАО Прогресс | 235-610 | |
| ОАО Вымпел | 222-65-11 |
Для моделирования отношений (связей) реального мира в базе данных применяют внешние ключи. Связи между реальными объектами могут быть очень сложными, предприятие имеет контакт со многими физическими и юридическими лицами (и все это одновременно). В реляционной модели данных в одно и то же время могут быть связаны из трех способов: «один-к-одному», «один-ко-многим» и «многие-ко-многим».
Две таблицы связаны отношением «один-к-одному» (1:1), если каждой строке первой в таблице соответствует не более одной строки в другой таблице. В действительности отношения «один-к-одному» встречаются только с целью упрощения базы данных, например, когда одну таблицу необходимо разбить на две и более таблиц из соображения безопасности, производительности или из-за ограничения на количество столбцов. Например, в базе данных риэлтерской компании следует хранить сведения о характеристиках продаваемых объектов недвижимости, но информацию о фактическом адресе недвижимого объекта надлежит поместить в отдельную таблицу, доступ к которой должен быть более ограниченным. Таблицы, связанные отношением «один-к-одному», всегда должны иметь одинаковый первичный ключ, служащий для объединения данных.
Две таблицы связаны отношением «один-ко-многим» (1:М), если каждой строке в первой таблице соответствует ни одной, одна или много строк во второй таблице, но каждой строке во второй таблице соответствует только одна строка в первой таблице. Как видно из таблицы 2.2, в каждом городе может быть несколько клиентов. Поэтому таблица Города связана с таблицей Клиенты отношением «один-ко-многим».
Отношение «один-ко-многим» называется также отношением главный-подчиненный и является наиболее часто моделируемым типом отношений. Оно используется также для установления связи между основными таблицами базы данных с информацией, находящейся в справочных таблицах. Например, таблица Города имеет числовое поле Код города, являющееся внешним ключом к таблице Клиенты, где хранятся телефонные номера клиентов в каждом городе. В этом случае таблица Города связана с таблицей Клиенты отношением «один-ко-многим» (одна строка справочной таблицы Города может быть использована со многими или ни с одной строкой таблицы Клиенты).
Две таблицы связаны отношением «многие-ко-многим» (М:М), если каждой строке в первой таблице соответствует много срок во второй таблице и каждой строке во второй таблице соответствует много строк в первой таблице. Отношения типа «многие-ко-многим» (М:М) не могут быть смоделированы в программах реляционных баз данных напрямую – они должны быть представлены множеством отношений типа «один-ко-многим» (1:М). Например, одна товарная номенклатура может быть поставлена множеством поставщиков, а один поставщик может поставлять множество товарных номенклатур. Поэтому таблица Номенклатура и Поставщики будет связана отношением «многие-ко-многим» (М:М). Чтобы смоделировать такие отношения между двумя указанными таблицами, необходимо ввести третью таблицу Поставки, которая будет таблицей связи. Таким образом, отношение «многие-ко-многим» (М:М) между таблицами Номенклатура и Поставщики может быть разбито на два отношения «один-ко-многим»: таблицы Номенклатура и Поставки, а также Поставщики и Поставки связаны между собой отношением «один-ко-многим». Действительно, одна единица номенклатуры может присутствовать во множестве поставок, а один поставщик может осуществлять поставки множество раз.
Реляционная модель задает общие и специфические правила целостности. Общие правила целостности относятся ко всем базам данных и определяют целостность объекта и целостность на уровне ссылок.
Правило целостности объектов требует, чтобы первичные ключи таблиц не содержали неопределенных (пропущенных) данных. Ведь если первичный ключ таблицы не определен, то в такой таблице невозможно однозначно определить строку и обратиться к ней.
Правило целостности на уровне ссылок требует, чтобы база данных не содержала несогласованных значений внешних ключей, что означает:
- строка не может быть добавлена в таблицу с внешним ключом, если в связанной таблице отсутствует строка, на которую ссылается внешний ключ. Например, вы не можете ввести новую позицию номенклатуры, если в главной таблице отсутствует соответствующая ей категория;
- если первичный ключ записи первой таблицы, на которую ссылается по внешнему ключу записи из второй таблицы был изменен или была удалена вся строка. Например, вы не можете изменить или удалить какую-либо номенклатурную категорию из таблицы Категория, если по ней присутствует множество номенклатурных позиций товаров в таблице Номенклатура.
Все ограничения, которые связаны с целостностью и сопряжены с особенностями моделируемого процесса, называются специфическими правилами, или бизнес-правилами. Если их игнорировать, то очень скоро запущенная в эксплуатацию база данных будет содержать множество некорректных данных. В качестве примера приведем некоторые бизнес-правила, которые необходимо определить в базе данных, используемых на сервисном предприятии:
- дата приема заказа всегда должна быть больше или равна дате начала деятельности фирмы и меньше или равна текущей дате;
- время приема заказа должно указываться в пределах рабочего времени;
- дата и время выполнения заказа должны быть больше или равны дате и времени выполнения заказа;
- новые заказы не должны включать работы, которые фирмой уже не выполняются;
- возраст сотрудников должен быть старше 18 лет и т.д.
В процессе проектирования базы данных приходится принимать решения относительно того, как наилучшим образом представить некоторую систему из реального мира и построить ее модель в базе данных. Необходимо определить, какие таблицы создать, какие столбцы они будут содержать и какие связи будут между таблицами. Для решения всех этих вопросов служит процесс нормализации, т.е. упрощения структуры базы данных с целью ее оптимизации. Нормализация – это пошаговый процесс разбиения исходных таблиц на более простые, которые должны удовлетворять двум основным требованиям:
- между полями таблицы не должно быть нежелательных функциональных зависимостей;
- группировка полей в таблицах должна обеспечивать минимальное дублирование данных, эффективный поиск, обработку и обновление данных.
Сегодня определено 5 основных нормальных форм, каждая нормальная форма снимает определенные зависимости между полями и устраняет определенные трудности обработки данных.
Однако ближе для восприятия и использования на начальных этапах проектирования метод проектирования ER, поскольку он использует наглядное графическое представление структуры информации о предметной области и широко используется в средствах программного моделирования информационных систем.
[1] Информационные технологии управления : учеб. пособие / под. ред. Ю.М. Черкасова. М. : ИНФРА-М, 2001. С. 19–23, 26, 37–42.
* Куправа Т.А. Самоучитель Ассуss 97/2000. СПб. : Наука и техника, 2001. С. 9.
* Информационные технологии управления : учеб. пособие / под ред. Ю.М. Черкасова. М. : ИНФРА-М, 2001. С. 75–89.
* Савицкий Н.И. Технологии организации, хранения и обработки данных : учеб. пособие / Н.И. Савикий. М. : ИНФРА-М, 2001. С. 56–58, 39–44.