3. Базы данных

1.
ХРАНЕНИЕ ДАННЫХ
Данные компании - один из ее наиболее важных ресурсов. Тем не менее, само по
себе существование актуальных данных не гарантирует их полезность. Чтобы
нормально функционировать, организация должна иметь постоянный и легкий доступ к
своим данным. Поэтому те, для кого эти данные предназначены, должны понимать, как
данные организовываются и хранятся в ИС и как к ним можно получить доступ. В
сущности, им нужно знать, как управлять данными для получения максимальной
выгоды от их совместного использования.
1.1.
символы (значение данных), описывающее конкретный атрибут и запись, к которой
оно относится.
Родственные записи, сгруппированные вместе, образуют файл. Так, все записи о
дебиторских задолженностях клиентов хранятся в файле дебиторских счетов. Файлы,
содержащие связанные по смыслу данные, объединяются, образуя базу данных.
Централизованная координация файлов базы данных облегчает как обновление данных
так и доступ к ним пользователя. Например, файл дебиторских счетов может быть
объединен с файлами клиентов, продаж, другими файлами, чтобы сформировать базу
данных клиентов.
Рисунок 2.3
Файл дебиторских счетов
Основные понятия и определения
Легко представить, как трудно это было бы в организации найти конкретную счетфактуру, если бы все основные документы фирмы были произвольно свалены в
шкафах. К счастью, большинство архивов компаний организовываются для легкого
поиска. Точно так же, информация в БУИС может организовываться для легкого и
эффективного доступа. В этом разделе объясняются основные понятия и определения,
касающиеся хранения данных, используя пример хранения информации о дебиторских
счетах.
Сущность - это нечто, о чем хранится информация. Примерами сущностей
являются служащие, товарно-материальные ценности, счета клиентов. Каждая
сущность имеет атрибуты, или характеристики, которые подлежат учету и хранению.
Примеры атрибутов - оклад служащего, адрес клиента.
Символы - числа и буквы, скомбинированные осмысленным образом, образуют
значение данных. Например (см.рис.2.3), номер почтового ящика (значение данных)
является адресом (атрибутом) Первушина (сущности).
Обычно, каждый тип сущностей обладает одинаковым
Рисунок 2.2
набором атрибутов. Например, все служащие имеют свой
Иерархия
номер, оклад, домашний адрес. Специфические значения
элементов
данных этих атрибутов, однако, изменяются от одной
хранения данных
сущности к другой (оклад у разных служащих может быть
разный).
База
Системы электронной обработки данных (electronic data
данных
processing - EDP) хранят данные, организовывая более
мелкие единицы данных в большие, более значимые. Эта
иерархия хранения данных, начиная с полей (минимальный
Файл
элемент) и заканчивая базами данных (самый большой)
показана на рис.2.2. Значения данных физически хранятся в
области,
называемой
полем.
Несколько
полей
сгруппированные вместе, формируют запись, коллекцию
Запись
значений данных, которая описывает специфические
атрибуты сущности. На рис.2.3 каждая строка представляет
разные записи, а в каждом столбце - атрибут. На пересечении
Поле
каждой строки и столбца стоит поле, которое содержит
Атрибуты
3 записи
Customer
number
19283
35794
56987
Customer
name
Первушин
Вторяков
Третьяк
Address
П/Я 7
Кирова, 33
Ленина, 10
Credit
limit
3000
4500
2500
Balance
2450
1200
2400
Значения
данных
Отдельные поля
В этом файле дебиторских счетов хранится информацию о трех различных клиентах:
Первушине, Вторякове и Третьяке. Поэтому в файле три записи. Чтобы описать каждого
клиента, используются пять различных атрибутов: номер клиента, имя клиента, его адрес,
кредитный лимит и баланс. Это означает, что в каждой записи по пять полей. Каждое поле
содержит значение данных, которое описывает атрибут конкретной сущности (клиента). Так,
значение 19283 - номер клиента для Первушина.
1.2.
Метод баз данных
В течение многих лет компании создавали новые файлы и программы всякий раз,
когда возникала потребность в информации. Результатом было значительное
увеличение количества главных файлов, необходимых для поддержки новых
приложений. Например, Bank of America одно время имел 36 миллионов счетов
клиентов в 23 различных системах. Среди них одно из правительственных агентств
обнаружило данные, записанные сразу в 22 системах.
Метод баз данных рассматривает данные как организационный ресурс, который
должен использоваться и управляться в интересах всей организации, а не только
отдела, из которого исходят данные или функции, которые они описывают. Базы
данных сосредотачиваются на интеграции и использовании данных всеми
допущенными к ним пользователями. Интеграция достигается объединением главных
файлов в большие "хранилища" данных, которые доступны многим прикладным
программам. Пример - база данных служащих, которая объединяет данные, прежде
содержавшиеся в главных файлах платежных ведомостей, кадров, квалификации
работников. Рисунок 2.4 иллюстрирует различия между использованием файлов и
методом баз данных.
2
Программа, которая управляет и контролирует данные и обеспечивает связь между
данными и прикладными программами, называется системой управления базой
данных (СУБД, data base management system - DBMS). Совокупность базы данных,
СУБД и прикладных программ, которые имеют доступ к базе данных через СУБД
называется системой базы данных. Человека, ответственного за базу данных,
называют администратором базы данных (data base administrator - DBA).
Рисунок 2.4
Использование файлов и метод баз данных
Использование файлов
Файл #1
Эл-т A
Эл-т B
Эл-т C
Прикладная
программа
#1
Файл #2
Эл-т B
Эл-т D
Эл-т E
Прикладная
программа
#2
Файл #3
Эл-т B
Эл-т E
Эл-т F
Прикладная
программа
#3
1.3.
Прикладная
программа
#1
Система
управления
базой данных
В системах, использующих файлы, программисты должны знать, где физически
располагаются данные, формат записей, используемый прикладной программой.
Рисунок 2.5 показывает формат записи файла дебиторских счетов.
Рисунок 2.5
Формат записи файла дебиторских счетов
Customer
Customer
number
name
A
A
1.......... 10 11................ 30
A = Текстовое поле
N = Числовое поле
Прикладная
программа
#2
Прикладная
программа
#3
Логическое и физическое представление
Address
Credit Balance
limit
A
N
N
31 .............................. 60 61 ...68 69 .... 76
Предположим, что программист хочет, чтобы отчет по кредитам показывал номер
клиента, кредитный лимит и текущий баланс. Для того, чтобы написать программу, он
должен знать позицию и длину нужных полей (например, что номер клиента занимает
в записи с 1 по 10 позиции), а также формат каждого поля (текстовый или числовой).
Процесс становится еще более сложным, если требуются данные из различных файлов.
СУБД преодолевают эту проблему, разделяя хранение и использование элементов
данных. Метод баз данных обеспечивает два разных представления данных:
логическое и физическое. Логическое представление имеет дело с тем, как
пользователи организуют, просматривают, понимают данные и их отношения.
Физическое представление имеет дело с тем, как и где данные физически
размещаются и хранятся на дисках, магнитных лентах и других носителях. Рисунок 2.6
иллюстрирует эти два представления, используя данные дебиторских счетов.
Рисунок 2.6
Логическое и физическое представление данных БД клиентов
Логическое представление
Метод баз данных
База данных
Эл-т A
Эл-т B
Эл-т C
Эл-т D
Эл-т E
Эл-т F
данных
Данные
Физическое представление
Отчет по
кредитам
Customer number
Customer number
Credit limit
Customer name
Как
Balance
Address
данные
Credit limit
Финансовый
хранятс
Balance
отчет
я на
диске
Customer name
Address
Balance
Программа СУБД обеспечивает связь между тем, как данные физически хранятся на
дисках и логическим представлением каждого пользователя. СУБД управляет базой
данных так, чтобы пользователи могли получить к ним доступ, сделать запрос или
откорректировать независимо от того, как и где данные физически хранятся.
3
Пользователь отвечает только за определение логических требований к данным.
Отделение способа использования данных от того, как они хранятся и выбираются
означает, что пользователи могут менять свое логическое представление (требуемые
элементы данных), не делая изменений в физическом представлении (физическом
хранении данных). А администратор базы данных может изменить способ физического
хранения данных, даже если пользователи не изменили связанные с ними прикладные
программы.
Персонал, отвечающий за обработку данных, использует физическое
представление, чтобы сделать эффективным использование памяти и вычислительных
ресурсов. Администратор базы данных отвечает за такое физическое хранение данных,
при котором логические требования пользователей могут быть удовлетворены. Однако
программистам и пользователям обычно не нужно понимать физическое
представление, поскольку они изначально заинтересованы в использовании данных
независимо от того, как они хранятся.
Преимущества системы базы данных
Система базы данных дает следующие преимущества:
 Интеграция данных. Информация может объединяться неограниченным
количеством способов. Например, можно отвечать на такие вопросы, как "Какие
приспособления поставляются ОАО Электрон?" и "Кто из сотрудников говорит на
немецком языке?"
 Гибкость отчетов. Отчеты могут быть легко проверены и сгенерированы когда
требуется, не обязательно периодически (еженедельно или ежемесячно). Базу
данных можно просматривать, если требуется решить специфичную проблему или
получить более подробную информацию, лежащую в основе полученного отчета.
 Минимальная избыточность и совместимость данных. Поскольку элементы
данных обычно хранятся только один раз, избыточность данных и несовместимость
данных сведены к минимуму.
 Независимость данных. Поскольку данные и программы, которые их используют,
независимы друг от друга, можно изменять способы хранения данных без
необходимости изменять программы и наоборот. Это свойство упрощает как
программирование, так и управление данными.
 Централизованное управление данными. Управление данными более эффективное,
поскольку администратор базы данных, отвечает за координирование, контроль и
управление данными.
 Безопасность. Программное обеспечение СУБД имеет специальные встроенные
средства, например, пароли, которые помогают гарантировать сохранность данных.
 Перекрестно-функциональный анализ. В системе базы данных можно точно
определить связь между, например, продажами и затратами на рекламные кампании
и использовать это при подготовке управленческих отчетов.
1.4.
Как предприятия используют технологию баз
данных
Технология баз данных - жизненный факт и сегодня все мы находимся под ее
воздействием. Она используется в большинстве новых ИС. Многие менеджеры и
бухгалтеры работают с базами данных, они непосредственно занимаются вводом,
обработкой и запросами в базах данных. Они отвечают также за разработку и оценку
качества внутренних средств контроля, применяемых для обеспечения сохранности баз
данных. Некоторые из них выступают как эксперты, разработчики и управляющие по
отношению к базам данных.
Внешние базы данных
Многие организации занимаются сбором и хранением нужной информации во
"внешних" базах данных. Эти компании оказывают пользователям информационные
услуги за почасовую оплату или продают информацию на лазерных дисках. Приведем
несколько информационных областей, которые могут оказаться необходимыми:
 Налоговые услуги, содержащие федеральные и местные налоговые коды, правовые
нормы, налоговые руководства с перечнем кодов, объяснениями и примерами,
налоговые формы и инструкции, постановления налоговой инспекции и
регистрации частных предприятий.
 Бухгалтерские и аудиторские материалы, например, мнения аудиторских комиссий
и постановления о стандартах аудита.
 Полные годовые отчеты компании, включая замечания и отчеты ревизоров.
 Документы комиссии по ценным бумагам и биржам, списки должностных лиц и
директоров компаний и товариществ.
 Экономические прогнозы, котировки акций, другая финансовая информация.
 Федеральные и государственные законы и постановления.
 Списки предприятий, содержащие информацию о миллионах компаний.
 Литературные ссылки и полные тексты сотен периодических изданий.
Внутренние базы данных
Не только для бухучета, но и для многих других функциональных областей
создаются внутренние базы данных, чтобы получить преимущество в конкурентной
борьбе. Обследование 1997 года в США показало, что 60% производителей и
предприятий розничной торговли сейчас формируют маркетинговую базу данных, 10%
планируют это делать и 90% полагают, что им нужна маркетинговая база данных,
чтобы оставаться конкурентоспособными.
Сегодня на предприятиях существует тенденция перехода от баз данных,
специализированных для выполнения определенных функций, к складам данных,
которые в сущности являются едиными базами данных, обслуживающими потребности
всех пользователей. В результате традиционно отдельные базы данных будут
интегрироваться. Вместо того, чтобы иметь маркетинговую, бухгалтерскую и
производственную базы данных, предприятия стремятся их объединять.
4
2.
ОБРАБОТКА ДАННЫХ
Наиболее общим типом обработки данных являются операции над данными периодическое выполнение операций для коррекции хранящихся данных. Обычно
используются четыре вида операций с данными. Добавление - включение новых
записей в файл. Удаление - уничтожение записи в файле. Обновление - периодическая
коррекция существующих записей, например, увеличение или уменьшение текущего
баланса на сумму оформленной сделки. Изменение - обновление полей, которое
происходит нерегулярно, например, при изменении кредитных ставок или почтового
адреса.
На рисунке 2.8 показана последовательность операций над данными, необходимая
для коррекции записи дебиторского счета при совершении продажи. Здесь для поиска
двух сопоставимых записей используется номер счета. Сумма продажи (360)
добавляется к балансу счета (1500), чтобы получить новый текущий баланс (1860).
Рисунок 2.8
Пример обновления файла
Номер
счета
0123
ДАННЫЕ ОБ ОПЕРАЦИИ
Тип
Дата
Номер
операции
операции
документ
а
Продажа
19.02.98
9876
ЗАПИСЬ ДЕБИТОРСКОГО СЧЕТА
Номер Кредитны Предыд. Текущ.
счета
й лимит
баланс
баланс
0123
2000.00
1000.00
1500.00
ОБНОВЛЕННАЯ ЗАПИСЬ ДЕБИТОРСКОГО
СЧЕТА
Номер
Кредитны Предыд Текущ.
счета
й лимит
баланс
баланс
0123
2000.00
1500.00
1860.00
Сумма
операции
360.00
ПРОЦЕСС
ОБНОВЛЕНИЯ ФАЙЛА
 Проверка точности
данных об операции
 Поиск записи
дебиторского счета по
первичному ключу
 Добавление суммы
операции к текущему
балансу
 Сравнение нового
баланса с кредитным
лимитом
 Повтор для всех
остальных операций
 Печать отчета
Обработка данных может включать и другие операции:
 Расчет - любая форма математической обработки одной записи.
 Сравнение - проверка двух или более элементов данных, например, объем запаса
на складе с точкой производства заказа, чтобы определить какой из них больше,
меньше или они равны.
 Подытоживание - объединение данных многих записей в значимый итог.
 Фильтрация - исключение лишних данных из последующей обработки.
 Поиск - выбор элементов данных из памяти для обрабатки или вывода.
2.1.
Первичные и вторичные ключи
Обычно записи обновляются, хранятся и извлекаются с использованием
идентификатора, который называется ключом. Основная цель первичного ключа однозначно идентифицировать каждую запись. В таблице 2.1 перечислены некоторые
часто используемые в организациях записи данных, для каждой из которых указаны
первичный ключ и два или более вторичных ключа.
Вторичный ключ - это другое поле, используемое для идентификации записи, хотя
от него не требуется быть уникальным для каждой записи. Вторичные ключи можно
использовать для сортировки записей. Например, чтобы записывать текущие оценки
студентов в компьютеризованный журнал, файл лучше отсортировать по фамилиям
студентов в алфавитном порядке. Определив итоговые оценки, преподаватель может
захотеть увидеть тот же файл в порядке убывания оценок. В этом примере уникальный
идентификатор - фамилия - является первичным ключом, а заработанные итоговые
оценки - вторичный ключ.
Обычно выбор подходящего первичного ключа для каждой записи очевиден.
Например, номер клиента для файла клиентов и номер счета для файла счет-фактур.
Выбор вторичных ключей тоже важен, поскольку он может улучшить эффективность
обработки базы данных, облегчить поиск информации. Наиболее подходящими
вторичными ключами являются те элементы данных, которые определяют какие-то
свойства, остающиеся общими внутри группы записей. Примеры - срок истечения
счет-фактуры, номер отдела служащего или код места размещения оборудования.
Таблица 2.1
Примеры ключей для типичных записей
Тип записи
Платежная ведом
Клиенты
Запасные части
Процесс работы
Готовые товары
Главная книга
Основные фонды
Кредитные счета
3.
Первичный ключ
Номер работника
Номер счета
Учетный код
Номер этапа
Номер изделия
Код счета
Номер фонда
Номер поставщика
Вторичный ключ
Имя работника, дата выплаты, отдел
Имя клиента, баланс, кредитный предел
Размещение, описание, поставщик
Размещение, дата начала
Размещение, цена
Номер отдела, текущий баланс
Размещение, дата покупки, поставщик
Срок оплаты, поставщик
Базы данных
В ИС (информационных системах) одним из главных инструментов моделирования
деятельности организации являются базы данных. В этом разделе обсуждается: Как ИС
моделирует деятельность организации. Что нужно знать экспертам организации о
5
разработке баз данных.
3.1.
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ
Данные организации, которая использует ИС, являются одним из ее главных
активов. Они хранятся в базах данных (БД) и предоставляются пользователям,
интересующимся различными вопросами. Например, менеджер по продажам может
поинтересоваться списком клиентов в табличной форме, производственный менеджер заказами, находящимися на исполнении, высшее руководство может захотеть
проанализировать структуру продаж в графической форме по регионам или магазинам.
Все это различные примеры логического представления данных. И хотя существует
огромное количество разных способов просмотреть данные, все же они не хранятся в
форме, сразу пригодной для каждого из таких представлений. Данные хранятся в
едином физическом представлении, например, в индексно-последовательных файлах.
Одной из задач системы управления базой данных (СУБД, или database management
system - DBMS) является перевод логического представления каждого пользователя в
физическое представление данных, чтобы они могли просмотреть то, что хотят.
Рисунок 3.1
Функция СУБД
Просроченные кредиты
----------------------------------ФИО
Баланс Задержка
----------- --------- ----------Иванов
2354
23
Петров
132
32
Сидоров
3334
65
Логическое
представление
данных для
двух пользователей:
А
В
Продажи по регионам
30%
30%
15%
25%
СУБД
Операционная
система
База
данных
СУБД переводит
логическое представление в
команды, по которым
данные должны выбираться
из БД
Операционная система
переводит команды СУБД в
команды для выбора
данных с дисков.
Часто физическое представление данных сильно отличается от того, как
пользователи их получают. Например, баланс клиента, его имя и кредитная история
могут храниться в разных файлах и даже на разных компьютерах. СУБД скрывает
детали физического представления от пользователей, чтобы они могли
сконцентрироваться на логических взаимоотношениях различных показателей.
Чтобы обеспечить предоставление нужных данных нужным пользователям и скрыть
информацию от тех, кто ее не должен знать, в базах данных используется два
механизма - авторизация пользователей (каждый, кто обращается к БД, должен
назвать свое имя и свой пароль) и справочник данных (специальный служебный
файл, который для каждого элемента данных содержит его описание, в том числе кому разрешен его просмотр), который часто называют словарем данных, т.к. от его
содержимого зависит, на каком языке “разговривает” БД, как называет свои элементы.
3.1.1. Схемы баз данных
Схема описывает логическую структуру БД. Существует три уровня схем:
концептуальный, внешний и внутренний.
Концептуальная схема дает общий взгляд на организацию всей БД. Она
перечисляет все элементы данных и отношения между ними. Внешняя схема состоит
из набора логических представлений пользователей, каждое из которых называется
подсхемой. Внутренняя схема представляет структуру базы данных. Она описывает,
как данные на самом деле хранятся, включая информацию об указателях, индексах,
длине записей и т.д. Между схемами этих уровней существует соответствие,
называемое отображением. Это правила преобразования одного представления в
другое. СУБД использует отображения схем для вывода и ввода данных.
При создании БД для ИС эксперты организации (менеджеры, бухгалтеры)
привлекаются для разработки схем концептуального и внешнего уровня. Поэтому им
важно понимать разницу между этими типами схем. Например, для описания
розничных продаж база данных на концептуальном уровне может содержать
информацию о клиентах, продажах, кассовых операциях, продавцах и кассирах,
товарах, счетах. На внешнем уровне из этой схемы могут быть получены много
различных подсхем, каждая из которых предназначена для потребностей отдельных
пользователей и должна скрывать от них данные, не относящиеся к выполнению их
обязанностей. Так, внешняя подсхема для служащего, оформляющего заказы, может
содержать данные о кредитных лимитах и текущих балансах клиентов, количестве
товаров на складе и их ценах, но не будет включать информацию о закупочной
стоимости товаров или текущих банковских счетах компании. Внешняя подсхема для
служащих, обеспечивающих доставку товаров, будет содержать информацию об
адресах клиентов, но не об их текущих балансах.
6
Рисунок 3.2
Три уровня схем базы данных
Подсхема А
Подсхема В
Подсхема С
Шкаф .. 232
Стол .... 341
Диван .. 520
Стул ...... 45
Внешний уровень
Набор
индивидуальных
логических
представлений о
частях БД
логического представления для каждого пользователя и (4) определения ограничений,
обеспечивающих безопасность записей и полей БД.
Язык управления данными (ЯУД, или data manipulation language - DML)
используется для обслуживания БД, т.е. выполнения операций обновления, вставки,
удаления записей.
Язык описания запросов (ЯОЗ, или data query language - DQL) используется для
выбора данных из БД, их упорядочения и предоставления в ответ на запрос
пользователей.
Отображение внешних представлений на концептуальную схему
Товары
Продажи
Клиенты
Концептуальный
уровень
Общий взгляд на
всю базу данных
Кассовые
операции
Отображение концептуальной схемы на внутреннее
представление
Запись о запасах
Item number
- integer (5), non-null, index = itemx
Description
- character (15)
Cost
- currency (6,2)
и т.д.
Запись о продажах
Invoice number - integer (6), non-null, index = salesx
и т.д.
Внутренний
уровень
Детали хранения
данных - структура
записей, адреса,
индексы и т.д.
3.1.3. Функции СУБД и ее пользователей
Обычно пользователи имеют доступ к языку описания запросов. Что касается ЯОД
и ЯУД, то доступ к ним предоставляется только тем служащим, которые отвечают за
администрирование и программирование СУБД. Это просто означает, что изменять
содержимое БД могут не все пользователи, а только ответственные за это лица.
Распределение обязанностей таких привилегированных пользователей - существенная
часть жизни БД.
Администратор данных отвечает за разработку политики и процедур управления
всеми данными организации, а не только данными, хранящимися в БД. Другими
словами, администратор данных отвечает за информационные потребности
организации и в частности решает, какие данные будут храниться в БД.
Администратор базы данных отвечает за координацию, контроль и управление
БД. Он должен беспокоиться не только о пользователях и их информационных нуждах,
но и о том, как БД работает и как в ней хранятся данные. Основные обязанности
администратора БД - создание логической модели БД, установка стандартов данных,
одобрение изменений в структуре БД, разработка методов выбора данных в
соответствии с требованиями пользователей, определение и обслуживание физической
структуры БД, ведение справочника данных, разработка и реализация методов
контроля для обеспечения точности и сохранности БД. Для выполнения этих задач
администратор БД использует ЯОД.
Прикладные программисты пишут программы, призванные взаимодействовать с
БД. Они используют ЯУД для доступа и изменения содержимого БД.
3.2.
3.1.2. Использование языков СУБД
Любая СУБД должна обеспечивать три базовых функции - создание, изменение и
запросы к базе данных. Наборы команд, которые используются для выполнения этих
функций, называются соответственно языком описания данных, языком управления
данными и языком описания запросов. Эти языки призваны упростить работу с БД,
поскольку при работе с данными позволяют оперировать именами полей, таблиц,
индексов вместо описания физического расположения этих элементов.
Язык описания данных (ЯОД, или data definition language - DDL) используется для
(1) построения справочника данных, (2) создания или инициализации БД, (3) описания
РЕЛЯЦИОННЫЕ БАЗЫ ДАННЫХ
СУБД характеризуются различными логическими моделями, на которых они
основаны. Модель данных - это абстрактное представление о содержимом БД.
3.2.1. Реляционная модель данных
Большинство современных СУБД являются реляционными и используют
реляционную модель данных, которая представляет данные в виде таблиц. Однако
следует помнить, что в терминах реляционной модели описываются только
концептуальная и внешняя схемы, а на внутреннем уровне данные хранятся не в
таблицах. Каждая таблица представляет одну сущность (например, товар), каждая
строка в таблице содержит данные об одном экземпляре этой сущности (например, о
7
виде товара). Каждый столбец таблицы соответствует одному атрибуту сущности
(например, цене, коду поставщика или количеству).
Рисунок 3.3
Код
товара
1036
1038
1039
Таблицы видов товаров и их поставщиков
Описание
Холодильник
Холодильник
Стиральная машина
Код
поставщика
10011
10023
10034
Код
поставщика
10023
10034
10034
Количество
на складе
23
0
52
Описание
Адрес
“Горизонт”
“Бирюса”
BOSS
Россия, …
Россия, …
ФРГ, …
Цена
2310
3100
2500
Реляционная модель данных накладывает ограничения на структуру таблиц,
которые призваны обеспечить целостность и точность трактовки содержащихся в них
данных. Некоторые из них кажутся очевидными, но они полезны на этапе
моделирования данных.
1. Первичный ключ должен быть единственным. Первичный ключ - это атрибут,
который однозначно определяет каждую строку таблицы (например, код товара
может быть первичным ключом для таблицы товаров). Это ограничение еще
называют правилом целостности сущности, т.к. если у двух экземпляров
сущности один первичный ключ, то их невозможно отличить.
2. Каждый внешний ключ должен быть либо пустым, либо соответствовать одному
из значений первичного ключа в другой таблице. Внешний ключ - это атрибут
таблицы, который является первичным ключом другой таблицы. Внешние ключи
используются для описания связей между сущностями (например, код поставщика в
таблице видов товаров задает связь с таблицей поставщиков, что описывает
принадлежность товаров тому или иному поставщику). Это ограничение называют
правилом ссылочной целостности (например, если в таблице товаров указан код
поставщика 1010, то это означает, что поставщик неизвестен или данные о нем
утеряны, поэтому в таких случаях вместо просмотра таблицы поставщиков коду
поставщика назначают пустое значение).
3. Каждый столбец таблицы должен описывать свойство сущности, определенной
первичным ключом (например, в таблице товаров не должно встречаться имя
покупателя, иначе получится, что этот товар предназначен только для одного
покупателя).
4. В каждой строке таблицы должно содержаться только одно значение (например,
таблица поставщиков содержит в каждой строке описание одного и только одного
поставщика).
5. В каждом столбце все значения должны быть одного типа данных (например,
цена товаров не должна указываться прописью).
6. Порядок строк и столбцов не должен иметь значения. Это означает, что
переупорядочение строк или столбцов не должно менять смысла информации,
представленной в таблице. Данное свойство означает, например, что не должно
быть строк, меняющих смысл содержимого следующих за ней строк (то же самое и
для столбцов). Например, в таблице поставщиков не могут содержаться строки с
описанием “акционерные общества” или “частные предприятия”, которые
предполагают разбиение таблицы на части. Вместо этого надо вводить
дополнительный атрибут “тип предприятия”. Другой пример: холодильники в
таблице товаров не должны быть упорядочены по объему камеры, вместо этого
надо использовать отдельный атрибут.
3.2.2. Нормализация
Еще один вопрос, на который необходимо получить ответ - почему данные
разбиваются на таблицы, каждая из которых представляет отдельную сущность. Чтобы
на него ответить, рассмотрим альтернативный вариант - хранение данных в одной
таблице.
Рисунок 3.3а
Код
товара
1036
1038
1039
Хранение данных о товарах и поставщиках в общей таблице.
Описание
Холодильник
Холодильник
Стир. машина
Количество
на складе
23
0
52
Цена
2310
3100
2500
Описание
поставщика
“Бирюса”
BOSS
BOSS
Адрес
Россия,..
ФРГ,…
ФРГ,…
Отметим несколько недостатков такого подхода:
 Избыточность данных. Обратите внимание, что фирма BOSS в общей таблице
указана два раза. В больших базах данных при использовании такого подхода могут
быть объединены десятки таблиц и подобных повторений могут быть многие
тысячи. Результат - неэкономное расходование места на носителях данных и как
следствие - большой расход времени на поиск нужной информации.
 Аномалия обновления данных. Всякий раз, когда необходимо будет внести
изменения в данные о фирме (например, при изменении адреса), придется
переделывать несколько записей. В варианте с двумя таблицами данные хранятся
только в одном месте.
 Аномалия вставки записей. В общей таблице отсутствует поставщик “Горизонт”,
т.к. он реально не поставляет товары. Это означает, что учесть нового поставщика
можно будет только после того, как в таблице появится какой-то его товар.
 Аномалия удаления. Удаление из общей таблицы холодильника с кодом 1036
приведет к потере всех данных о поставщике “Бирюса”.
С помощью разбиения данных на таблицы эти недостатки исчезают, что дает
экономию места на носителях данных и намного облегчает работу с ними. При этом
само разбиение не является искусственным, а производится в соответствии с
8
внутренней логикой объектов-сущностей, которые моделируются, поэтому облегчается
не только оперирование с данными, но и общее понимание того, что содержится в базе
данных. Процесс следования правилам разработки реляционных таблиц, позволяющих
избежать перечисленных недостатков, называют нормализацией.
3.2.3. Запросы к реляционным базам данных
Реляционные БД выполняют три основных типа операций с таблицами при
выполнении запросов:
 Проектирование (PROJECT) - создание новой таблицы путем выбора заданных
столбцов из исходной таблицы (например, создание списка названий поставщиков).
 Выбор по условию (RESTRICT) - создание новой таблицы путем выбора из
исходной таблицы строк, удовлетворяющих заданным условиям (например, выбор
из таблицы товаров холодильников, которые имеются на складе).
 Объединение (JOIN) - создание новой таблицы путем выбора заданных столбцов из
двух или более таблиц (например, создание таблицы видов товаров с указанием их
цены и страны изготовления).
Важное свойство реляционной модели данных состоит в том, что результатом запроса
всегда является новая таблица и к ней может быть применен новый запрос. Это
позволяет выполнять вложенные запросы и делает языки описания запросов очень
мощным инструментом просмотра базы данных (пример простого вложенного запроса
- после объединения таблицы товаров с указанием стран изготовления, можно выбрать
товары, изготовленные за рубежом). При этом физически последовательности таблиц
при выполнении вложенных запросов могут и не создаваться.
Кроме того, запросы позволяют упорядочивать таблицы (например, выбранные
товары в порядке возрастания цены), а также делать итоговые вычисления, используя
операцию группировки (например, можно посчитать общую стоимость хранимых на
складе холодильников, сгруппировав строки таблицы товаров по описанию товара).
В большинстве случаев пользователю даже не обязательно знать ЯОЗ, потому что
для выбора из БД часто встречающихся, стандартных типов информации создаются
специальные формы, с которыми легко работать. Однако для понимания того, что
можно получить из базы данных, надо представлять, как работает язык описания
запросов. Реляционные языки описания запросов можно разделить на две большие
категории: текстовые ЯОЗ и графические ЯОЗ. Ниже на примерах рассматриваются
два таких языка - SQL и QBE.
SQL
Самым известным среди текстовых ЯОЗ является SQL (structured query language).
Он стал стандартом, который поддерживают большинство СУБД, благодаря чему
возможно обращение к внешним базам данных с помощью стандартного программного
обеспечения. Большинство запросов на SQL используют пять ключевых слов:
 SELECT. Перечисляет столбцы, которые должны быть выбраны из таблиц в ответ
на запрос. Выполняет операцию проектирования.
 FROM. Перечисляет таблицы, из которых производится выбор. Реализует операцию
объединения, если названы две или больше таблиц.
 WHERE. Определяет условие, по которому будут выбраны строки в ответ на запрос.
Используется для задания выбора по условию.
 ORDER BY. Называет столбец, в соответствии с которым будут упорядочены
строки в ответе на запрос. Кроме этого задается способ упорядочения - по
возрастанию (ASCENDING) или по убыванию (DESCENDING).
 GROUP BY. Называет столбец, по значению которого строки группируются, чтобы
в каждой группе подсчитать какой-либо итог, например, сумму, максимум или
минимум значений другого столбца. Что именно будет подсчитано, определяется
при использовании ключевого слова SELECT (см. примеры).
Разберем на примерах простые способы применения ключевых слов SQL для
формирования запросов. Примеры будут касаться следующей БД, состоящей из 4
таблиц:
Таблица счет-фактур Invoice
Invoice#
101
102
103
104
105
Date
15.10.97
15.10.97
28.10.97
31.10.97
14.11.97
Salesperson
Иванов
Петров
Сидоров
Иванов
Иванов
Customer#
151
152
151
152
153
Таблица строк в счет-фактурах LineItem
Invoice#
101
101
102
102
102
103
104
105
105
105
Item#
10
50
10
20
30
50
40
10
20
30
Quantity
2
1
1
3
2
2
1
3
1
2
Amount
4000
4200
2000
10500
8000
8400
3800
6000
3500
8000
Таблица клиентов Customer
Customer#
151
152
153
Name
Первушин
Вторяков
Третьяк
Address
634014 Томск..
634028 Томск..
634045 Томск..
Total
8200
20500
8400
3800
17500
9
Таблица видов товаров Inventory
Item#
10
20
30
40
50
Price
2000
3500
4000
3800
4200
Description
Телевизор
Морозильник
Холодильник
Кух. плита
Стир. машина
Попробуйте проследить по этим таблицам, как будут выполняться следующие ниже
запросы, используя связи по ключам. Запрос выполняется перебором строк в таблицах.
Перебираются сверху вниз по очереди строки таблиц, атрибуты которых указаны в
SELECT. При этом WHERE обеспечивает отбор записей по условию. Если в запросе
встречаются данные из разных таблиц, то для выяснения вопроса, какие именно строки
надо сравнивать, используется сопоставление их ключей (первичного и внешнего),
которые тоже появляются в условии. Чтобы облегчить задачу прослеживания
выполнения запроса, задайте себе вопрос: “как бы я искал ответ, используя эти
таблицы?” или просто проверьте, правильно ли указаны ответы на каждый запрос.
Запрос 1.
SQL:
SELECT
FROM
WHERE
ORDER BY
Здесь:
SELECT
FROM
WHERE
Показать даты и общие суммы покупок, сделанных в октябре,
упорядочив их по убыванию сумм.
Date, Total
Invoice
Date BETWEEN 01.10.97 AND 31.10.97
Total, DESCENDING
делает проектирование выбирая Date и Total
определяет, что Date и Total - из таблицы Invoice
делает выбор по условию. Связи по ключам не нужны, т.к.
просматривается только одна таблица.
ORDER BY упорядочивает результат, поэтому
Ответ на запрос:
Date
15.10.97
28.10.97
15.10.97
31.10.97
Total
20500
8400
8200
3800
Запрос 2.
SQL:
SELECT
FROM
WHERE
Здесь:
SELECT делает проектирование
FROM
определяет, с какими таблицами идет работа
WHERE делает выбор по сложному условию. Первая строка условия связывает
первичный ключ таблицы Customer с внешним ключом таблицы
Invoice. Это обеспечивает, что из таблицы Invoice будут выбраны
только счет-фактуры Первушина. Далее, поскольку атрибут Customer#
присутствует в обоих таблицах, явно указаны их имена. Сравните это
с обращением к Invoice# в SELECT. Хотя Invoice# и присутствует в
двух таблицах, но одна из них (LineItem) не является предметом
запроса (см. FROM), поэтому и не требуется явного указания имени
таблицы.
Ответ на запрос:
Invoice#
101
103
Salesperson
Иванов
Сидоров
Запрос 3.
SQL:
SELECT
FROM
WHERE
Name
Первушин
Первушин
Сколько телевизоров продано в октябре?
SUM(Quantity)
LineItem, Invoice, Inventory
LineItem.Item# = Inventory.Item# AND
Description = ‘Телевизор’ AND
LineItem.Invoice# = Invoice.Invoice# AND
Date BETWEEN 01.10.97 AND 31.10.97
Здесь:
SELECT делает проектирование и задает операцию подсчета суммы
FROM
определяет, какие таблицы придется просмотреть
WHERE делает выбор по сложному условию, т.е. определяет, какие
количества,
указанные
в
таблице
LineItem
подвергнутся
суммированию. Первая и третья строки условия обеспечивают
правильные связи между строками таблиц по ключам (подобно
запросу 2).
Ответ на запрос:
SUM(Quantity)
3
Назвать номера всех счет-фактур Первушина и тех, кто их
оформлял.
Invoice#, Salesperson, Name
Invoice, Customer
Invoice.Customer# = Customer.Customer# AND
Name = ’Первушин’
Запрос 4.
SQL:
SELECT
FROM
WHERE
Показать имена и адреса всех клиентов, купивших телевизоры в
октябре.
Name, Address
Customer, Invoice, LineItem, Inventory
Date BETWEEN 01.10.97 AND 31.10.97 AND
Description = ‘Телевизор’ AND
LineItem.Invoice# = Invoice.Invoice# AND
Invoice.Customer# = Customer.Customer# AND
10
LineItem.Item# = Inventory.Item#
Запрос 1.
Показать даты и общие суммы покупок, сделанных в октябре,
упорядочив их по убыванию сумм.
Здесь:
SELECT делает проектирование
FROM
определяет, с какими таблицами идет работа (все 4!)
WHERE делает выбор по сложному условию. Последние три условия - задают
связи по ключам. Первые две строки определяют отбор записей из
таблицы клиентов.
Ответ на запрос:
Name
Первушин
Вторяков
Address
634014 Томск..
634028 Томск..
Запрос 5.
На какую сумму оформил продажи каждый продавец?
SQL:
SELECT
SUM(Total), Salesperson
FROM
Invoice
GROUP BY Salesperson
Здесь:
SELECT делает проектирование
FROM
определяет таблицу
GROUP BY сообщает СУБД, что для суммирования должны быть отобраны
общие суммы из таблицы счет-фактур с одинаковым значением поля
оформлявшего их продавца.
Ответ на запрос:
SUM(Total)
29500
20500
8400
Salesperson
Иванов
Петров
Сидоров
QBE
Графические ЯОЗ называют QBE - query by example. Многие СУБД предоставляют
средства формирования QBE запросов в дополнение к SQL. Суть состоит в том, что
пользователь меньше имеет дело с ключевыми словами, а просто на экране в
специальную графическую форму вставляет по выбору различные элементы запроса названия таблиц, атрибутов, операций и некоторые специальные обозначения. СУБД
затем переводит запрос на SQL и выполняет его. Чтобы пояснить суть QBE, приведем
несколько примеров, повторяющих 1-ый и 4-ый примеры для SQL. Сравните их.
QBE:
Invoice
Invoice#
---
Date
.+. _Month
Salesperson
---
Customer#
---
Total
.+. _Total
Conditions:
Month BETWEEN 1.10.97, 31.10.97
Order by:
Primary:
Total, ACCENDING
Secondary: -----В этом запросе символ ‘.+.’ означает, что данное поле должно появиться в ответе на
запрос. Закрашены элементы, которые можно не вводить, а выбирать из списка
имеющихся вариантов. Идентификаторы _Month и _Total - вводят обозначения для
атрибутов, которые затем используются в разделах условий (Conditions) и
упорядочения (Order by). Обозначение ‘---’ означает, что из предложенных в этом
месте вариантов в запросе пользователем ничего не выбрано
Запрос 4.
Показать имена и адреса всех клиентов, купивших телевизоры в
октябре.
QBE:
Invoice
Invoice#
--- _sale
Date
--- _Month
Salesperson
---
Name
.+.
Address
.+.
Customer#
--- _cust
Total
---
Customer
Customer#
--- _cust
LineItem
Invoice#
--- _sale
Item#
--- _tv
Quantity
---
Amount
---
Inventory
Item#
--- _tv
Price
---
Description
--- Телевизор
Conditions:
Month BETWEEN 1.10.97, 31.10.97
Order by:
Primary:
-----В этом запросе значение “Телевизор” в таблице Inventory представляет условие равенство для выбора. Идентификаторы _cust (для Customer#), _sale (для Invoice#), _tv
(для Item#) используются для описания отношений между таблицами, символизируя,
что при просмотре двух таблиц ключевые атрибуты должны быть равны. Поскольку
условия - равенства задаются таким образом, в разделе Conditions присутствует только
ограничение на дату оформления продажи.
В некоторых СУБД отношения задаются один раз и затем поддерживаются
11
автоматически. В этом случае в форме QBE присутствие _cust, _sale и _tv не нужно и
даже отпадает необходимость показывать таблицу LineItem. Такой упрощенный запрос
будет выглядеть так:
QBE:
Invoice
Date
--- _Month
Salesperson
---
Total
---
Customer
Name
.+.
Address
.+.
Inventory
Price
---
Description
--- Телевизор
Conditions:
Month BETWEEN 1.10.97, 31.10.97
3.3.
МОДЕЛИРОВАНИЕ ДАННЫХ
Моделирование данных - это процесс определения базы данных с целью
правдоподобно отразить в ней функционирование организации. Задача, следовательно,
состоит в том, чтобы надежно собирать и сохранять данные о всякой деятельности,
которую организация хочет планировать, контролировать или оценивать. Эксперты
организации (менеджеры, бухгалтеры) обязательно вовлекаются в создание БД и при
этом сталкиваются по крайней мере с двумя инструментами - REA моделью данных и
E-R диаграммами, которые используются на этапе разработки БД.
котором подлежат учету.
 Участники (Agents) этих событий. Участники как сущности - это обычно группы
людей, о которых организация собирает данные с целью лучше планировать,
контролировать или оценивать их деятельность. Участники всегда вовлечены или
имеют отношение к каким-то событиям. Например, продавцы совершают сделки
продаж, кассиры принимают деньги, поставщики предоставляют товар, клиенты
производят заказы и т.д.
Таким образом, REA модель с точки зрения организации предназначена для описания
учета как бухгалтерских, так и управленческих данных. Например, кроме даты
продажи может учитываться и время дня, чтобы по множеству записей о продажах
можно было планировать потребность в обслуживающем персонале в течение рабочего
дня и тем самым получить возможность адекватно составлять скользящие графики
работы служащих.
3.3.2. E-R диаграммы
Рисунок 3.4
E-R диаграмма, описывающая продажи
РЕСУРСЫ
Виды
товаров
СОБЫТИЯ
*
Продается
*
Продажи
УЧАСТНИКИ
*
1
Продавцы
*
*
Кому
3.3.1. REA модель данных
REA модель данных была специально создана для разработки БД, предназначенных
для учета операций в организациях. REA - это английские начальные буквы трех
фундаментальных типов сущностей:
 Ресурсы (Resources), приобретаемые и используемые организацией. Большинство
ресурсов организации традиционно относят к ее активам. Это деньги, материальнопроизводственные запасы, недвижимость и т.д. То есть активы, которые
подвергаются учету. Однако для организации может быть важно учитывать и что-то
другое, например, заказы клиентов.
 События (Events), которые происходят в организации. В широком понимании - это
любая деятельность организации, изменяющая состояние ресурсов. В REA модели
событиями считаются не только традиционные бухгалтерские операции (продажи,
покупки, выплата зарплаты и т.д.), но и другие операции, о которых организация
хочет собрать данные (оформление заказов клиентов, стадии их прохождения и др.).
Однако такие события должны напрямую влиять на ресурсы. Например, перенос
данных из журнала в главную книгу не будет являться событием, если только какойто из этих документов не рассматривается как ресурс организации, записи в
Оформляют
Оплата
за
1
Клиенты
*
От
кого
1
*
*
1
*
УвеличеПолучаКассиры
Платежи
ние
ют
E-R диаграммы (Entity-Relationship, Сущность-Отношение) предназначены для
графического изображения схемы БД. Они показывают сущности в виде
прямоугольников и отношения между ними в виде линий. Такой простой прием
позволяет при разработке БД охватывать взором сложные схемы, иногда состоящие из
десятков сущностей, скрывая детали, несущественные на определенном этапе. Для
примера рассмотрим E-R диаграмму на рис.3.4, описывающую продажи в розничной
торговле. Для упрощения в ней моделируются только два типа событий: оформление
Деньги
1
12
продажи и прием платежа.
REA модель, на основе которой построена данная диаграмма, состоит из 7
сущностей, информация о которых подлежит учету. Поскольку события платежей и
продаж являются сделками, то каждое из них связано с двумя участниками и одним
предметом сделки. Каждое отношение на диаграмме имеет название-связку, которое
позволяет просто читать его смысл (продажи кому? - клиентам, платеж в уплату за
продажу и т.д. Продолжите сами для остальных отношений).
В дальнейшем каждая из сущностей будет описана в виде таблицы, содержащей их
атрибуты-столбцы и экземпляры-строки. Однако на E-R диаграмме эти подробности
скрыты, позволяя сосредоточиться на разработке концептуальной схемы БД.
На диаграмме имеются символы ‘1’ или ‘*’ между каждой сущностью и
отношением. Они описывают характер отношения между двумя сущностями. По
характеру отношения бывают трех типов: один к одному (1:1), один ко многим (1:*) и
многие ко многим (*:*).
Характер отношения можно определить, рассматривая его смысл. Например,
отношение между кассирами и платежами состоит в том, что один кассир может
принимать много платежей (*). В то же время каждый отдельный платеж не может
быть принят несколькими кассирами, а только одним (1).
Аналогично, характер отношения между товарами и продажами - многие ко многим
(*:*), т.к. один вид товара может быть упомянут во многих сделках продаж (*) и
предметом каждой сделки может служить не один, а сразу несколько видов товаров (*).
Характер отношения играет важную роль в моделировании деятельности
организации с помощью реляционных БД. Чтобы это увидеть, рассмотрим возможные
отношения между продажами и платежами:
Рисунок 3.5
Характер отношения между продажами и платежами
Отношение один к одному (1:1)
Продажи
1
Оплата
за
1
Платежи
Отношение один ко многим (1:*)
Продажи
1
Оплата
за
*
Платежи
Отношение многие к одному (*:1)
Продажи
*
Оплата
за
1
Платежи
Отношение многие ко многим (*:*)
Продажи
*
Оплата
за
*
Платежи
Пример - обмен валюты.
Каждая сделка заключается
отдельно только по одному
виду валюты.
Пример - продажа в кредит.
Каждая сделка продажи
оплачивается в несколько
приемов.
Пример - ежемесячная
оплата покупок, сделанных
при нескольких посещениях
магазина.
Пример - регулярные
взносы на приобретение
товаров. Дебиторские
задолженности.
Разработка E-R диаграммы может быть разложена на 4 шага:
 Выявление необходимых сущностей. Если мы пользуемся REA моделью, то этот
шаг всегда начинается с определения событий, связанных с деятельностью
организации. Продажи и платежи, поставки и покупки, прием и доставка заказов,
прием на работу и выплата вознаграждений персоналу, продвижения по службе все это примеры событий, которые организация может учитывать для обеспечения
лучшего принятия решений.
После выявления событий для каждого из них определяются ресурсы, состояние
которых изменяется после того, как событие произошло.
И наконец выявляются участники каждого события. Важно помнить, что в REA
модели под термином “участник” подразумевается не конкретный человек, а его
функция в организации. Поэтому один из кассиров и один из продавцов может быть
одним и тем же лицом, а для учета персонала при этом потребуется выделение
отдельной сущности.
При выявлении сущностей важно помнить, что в их число должны попасть
только те, которые связаны с проблемами, решаемыми с помощью БД. Иначе
организация рискует столкнуться с эффектом информационной перегрузки.
 Изображение сущностей на диаграмме. Поскольку сущности делятся на три
класса и события связаны как с ресурсами, так и с участниками, то прямоугольники
для каждой сущности помещаются в три столбца (слева направо): столбец ресурсов,
13
событий и участников. Это облегчает изображение отношений. Возможно, потом
для удобства и придется делать перестановки, но только внутри столбцов.
 Выявление и изображение отношений на диаграмме. При построении E-R
диаграммы не используются прямые отношения между ресурсами и участниками.
Это обусловлено самой природой событий, происходящих в организации, ведь само
воздействие участника на ресурс является событием. Изображение ромбов и линий,
связывающих две сущности для каждого отношения, несложная задача. Проблемы
чаще возникают при подборе удачного названия для отношения. Возможно также,
на этом шаге придется переставить на диаграмме некоторые сущности, чтобы связи
не перекрещивались.
 Определение характера отношений. Характер отношений не является чем-то
произвольным, а отражает их природу и определяется двумя факторами: (1)
политикой предприятия при проведении своих операций (пример - на рис.3.5) и (2)
спецификой операций (например, отношение клиенты-продажи на рис.3.4 - один ко
многим - отражает тот факт, что любая продажа оформляется только на одного
клиента).
Мы рассмотрели моделирование данных с помощью E-R диаграммы на простом
примере. Однако моделирование данных может быть сложным и длительным
процессом, сопровождающимся преодолением проблем, связанных со спецификой
отрасли и отдельного предприятия, и даже различиями в терминологии, используемой
в разных подразделениях организации.
3.3.3. Применение модели
Одно из преимуществ E-R диаграммы в том, что на ее основе достаточно просто
построить реляционную базу данных. На рис.3.6 приведен набор из 9 заполненных
значениями реляционных таблиц, служащих примером построения реляционной
модели в соответствии с E-R диаграммой продаж (рис.3.4). Столбцы атрибутов,
используемых в качестве первичных ключей, выделены серым цветом, а столбцы
внешних ключей обозначены наклонным шрифтом. Далее обсуждается процедура
этого преобразования.
Рисунок 3.6
Реляционные таблицы, соответствующие E-R диаграмме на рис.3.4
Таблица товаров Inventory
Item#
10
Description
Телевизор
20
Морозильник
30
Холодильник
40
Холодильник
50
Кух. плита
60
Ст. машина
70
Ст. машина
Cost
200
0
500
0
320
0
460
0
120
0
240
0
300
0
Price
2500
OnHand
6
5800
4
4000
8
5300
6
1500
4
2800
3
3400
0
Таблица продажи-товары Sales_Inventory
Invoice#
101
101
102
103
103
103
104
105
105
ltem#
10
30
60
20
30
60
40
30
60
QuantitySold
3
1
1
1
2
1
3
1
1
Таблица продаж Sales
Invoice#
101
102
103
104
105
Date
09.10.97
10.10.97
10.10.97
12.10.97
13.10.97
Salesperson#
101
102
101
101
102
Customer#
10001
10002
10004
10001
10003
Таблица продавцов Salesperson
Employee#
Name
DateHired
Salary
101
102
Иванов
Петров
23.09.95
25.09.96
1500
1800
Таблица кассиров Cashier
Employee#
Name
DateHired
Salary
121
122
Сидоров
Троицкий
03.03.97
21.11.95
1200
1600
Amount
7800
3360
15120
6360
8160
Time
0930
1045
1535
1230
1415
14
Таблица продажи-платежи Sales_CashCollections
Invoice#
101
103
104
Remittance#
122
123
122
Amount
7800
5000
2200
Таблица денег Cash
Account#
101
102
Account
139485736
283740134
Location
Банк 1
Банк 2
Таблица платежей CashCollections
Remittance#
122
123
Date
28.10.97
31.10.97
Customer#
10001
10004
Cashier#
121
122
Amount
10000
5000
Account#
101
101
Таблица клиентов Customer
Customer#
10001
10002
10003
10004
Name
Первушин
Вторяков
Третьяк
Четверкин
Address
634014 Томск..
634028 Томск..
634045 Томск..
634032 Томск..
CreditLimit
10000
6000
7500
3500
Опишем 4 шага, необходимые для перевода E-R диаграммы в схему реляционной
базы данных:
 Создание таблиц для каждой сущности и каждого отношения (*:*). Пример на
рис.3.4 требует создания 9 таблиц - 7 для каждой из сущностей и 2 для отношений
продажи-товары и продажи-платежи. Создание таблиц для отношений (*:*)
гарантирует выполнение требований нормализации. Каждой таблице дается имя по
названию соответствующей сущности (в примере - товары, деньги, продажи,
платежи, продавцы, клиенты, кассиры). Что касается имен таблиц, представляющих
отношения, то они обычно составляются из имен связываемых сущностей (в
примере - продажи-товары и продажи-платежи). Большинство СУБД накладывают
ограничения на имена таблиц и полей, например, допускают использование только
букв английского алфавита и некоторых символов.
 Определение атрибутов для каждой таблицы. Эта работа, как и создание E-R
диаграмм, делается с помощью специалистов фирмы, знающих особенности
циркулирующей в ней информации и потребности пользователей. Можно
перечислить некоторые правила при определении атрибутов:
Назначение первичных ключей каждой таблице. Одним или двумя атрибутами в
каждой таблице должны быть представлены первичные ключи. Для этого чаще
всего используются цифровые ключи, например, номер счета, табельный номер
работника, код товара, номер счет-фактуры и т.д. Обычно первичный ключ таблицы
- это один из ее атрибутов. Однако для таблиц, представляющих отношения (*:*), он
всегда состоит из двух атрибутов, которые представляют первичные ключи
связанных этим отношением таблиц. Такой многоатрибутный ключ называется
составным ключом. Например, первичный ключ таблицы продажи-товары будет
состоять из атрибутов - “номер счет-фактуры” (первичный ключ таблицы продаж) и
“код товара” (первичный ключ таблицы товаров). Столбцы первичных ключей на
рис.3.6 обозначены серым цветом.
Назначение таблицам неключевых атрибутов. Некоторые атрибуты (например,
дата и сумма продажи) нужны для правильной обработки данных и требуются для
отчетности. Другие атрибуты приписываются сущностям, чтобы обеспечить
информацию для более эффективного управления ресурсами организации
(например, табельный номер работника нужен не только чтобы начислять
комиссионные, но и чтобы оценивать работу служащих).
Каждый атрибут в таблице должен характеризовать первичный ключ или
быть внешним ключом. Это правило уже обсуждалось, когда мы вводили понятия
первичного и внешнего ключей при определении ограничений на структуру таблиц.
Здесь оно означает, что вся информация, не описывающая непосредственно данную
сущность, относится к другой сущности и находится в другой таблице, а внешний
ключ обеспечивает ссылку на эту информацию. Например, в таблице платежей
каждый платеж будет иметь атрибуты, описывающие его и только его - это номер
(первичный ключ), дата, сумма платежа, но вместо указания плательщика, кассира и
атрибутов счета в банке, будут присутствовать внешние ключи - код клиента,
табельный номер кассира и внутренний номер счета. Обратившись по этим ключам
в соответствующие таблицы, всегда можно узнать, например, имя клиента и
кассира, описание счета. По сути выполнение этого правила обеспечивает
отсутствие избыточности в БД. В самом деле, если бы вместо кода клиента в
таблице платежей присутствовало бы его описание, то фамилия Первушина, его
адрес и кредитный лимит повторились бы два раза, поскольку он сделал две
покупки.
 Реализация отношений (1:*). К этому этапу реляционная база данных полностью
моделирует только отношения (*:*). Отношения (1:*) моделируются с помощью
внешнего ключа. Для этого первичный ключ сущности, которая встречается в
отношении один раз, используется как внешний ключ сущности множественной
сущности. В нашем примере на рис.3.6 все внешние ключи предназначены для
моделирования отношений (1:*). Убедитесь в этом, сопоставив набор таблиц на
рис.3.6 с E-R диаграммой на рис.3.4. Это произошло потому, что на диаграмме нет
отношений (1:1).
 Реализация отношений (1:1). Отношения (1:1) между сущностями моделируются с
помощью вставки в одну из связанных таблиц внешнего ключа, который служит
первичным ключом другой таблицы. В принципе, вставлять внешний ключ можно в
любую из таблиц, но если мы имеем дело с отношением (1:1) между двумя
событиями, то внешний ключ вставляется в таблицу более позднего события.
Например, если бы на рис.3.4 отношение продажи-платежи было (1:1), что означает
взимание платежа за каждую покупку, то в наборе таблиц на рис.3.6 исчезла бы
таблица Sales_CashCollections, моделирующая отношение (*:*) а таблица
CashCollections могла бы выглядеть как на рис.3.7. В новом ее варианте появился
15
атрибут внешнего ключа Invoice# и за ненадобностью (платеж всегда принимается
сразу на всю сумму покупки) исчез атрибут Amount.
Рисунок 3.7
Remittance#
122
123
124
125
Таблица платежей CashCollections при моделировании отношения
(1:1)
Date
28.10.97
28.10.97
29.10.97
31.10.97
Invoice#
101
102
104
103
Customer#
10001
10002
10001
10004
Cashier#
121
122
121
122
Account#
101
101
101
101
Итак, мы разобрали основные этапы моделирования данных с помощью
реляционных баз данных. Знание основ этой работы необходимо экспертам
организации, которые будут принимать участие в создании ИС в качестве
консультантов и даже просто пользователей.
Задания
Чтобы проверить свое понимание, ответьте на следующие вопросы, используя
таблицы на рисунке 3.6:
Кто из работников обслуживал клиента Первушина?
Что покупал Первушин?
Сколько он задолжал на данный момент и за что?
Кому проданы стиральные машины?
Каков доход магазина (считая еще не уплаченные деньги)?
Можно ли посчитать прибыль и что для этого надо сделать?
Попробуйте по 4-м таблицам из раздела 3.23 составить E-R диаграмму (т.е. проделать
обратную операцию). Сколько сущностей получилось? Какой характер отношений
между ними?
3.4.
РАЗРАБОТКА БАЗ ДАННЫХ
Разработка базы данных - поэтапный процесс, в котором можно выделить 6 стадий.
Экспертам предприятия приходится участвовать в этом процессе почти на всех его
стадиях.
Рисунок 3.8
Стадии разработки базы данных
Эксплуатация
Планирование
Определение
требований
Моделирование
данных
Логическое
проектирование
Внедрение
Физическое
проектирование
Планирование. Первая стадия - начальное планирование для определения
потребностей и возможностей разработки новой системы. Цель - определить, является
ли предлагаемая система технологически и экономически возможной. Если это так, то
начинается новая стадия.
Определение требований включает определение области применения
предлагаемой базы данных, основных требований к программному и аппаратному
обеспечению, а также потребностей пользователей. Область применения определяется
в консультациях с руководством предприятия и отражает информационные
потребности организации, ее стратегические цели и задачи. После этого собирается
информация о таких факторах, как число пользователей и ожидаемый объем операций,
которые используются для определения основных требований к программному и
аппаратному обеспечению новой системы. Данные о потребностях пользователей
собираются различными методами, например, с помощью интервью или
анкетирования. Эти данные используются для предварительного определения
отдельных представлений пользователей (внешних подсхем), которые бы отражали как
требования обработки операций, так и требования процесса принятия решений. При
разработке базы данных приходится принимать во внимание несколько требований:
16
Полнота
Адекватность
Актуальность
Точность
Доступность
Эффективност
ь
Экономичност
ь
Безопасность
Гибкость
БД должна содержать все данные и отношения, нужные
различным пользователям. Интересы пользователей и
источников данных должны быть скоординированы.
Собираться и храниться должны только полезные и
относящиеся к делу данные.
Хранимые данные должны постоянно обновляться, чтобы
отразить текущее состояние дел.
В БД не должно быть ошибок и неточностей.
Хранимые данные должны быть доступны для всех
легальных пользователей в нужное им время.
На хранение данных должно тратиться не очень много
ресурсов, а время обновления, извлечения данных и
эксплуатация БД должно быть приемлемым.
Затраты на содержание БД не должны превышать выгод от ее
использования.
БД должна быть защищена от потери данных, разрушения и
несанкционированного доступа.
Возможные изменения в жизни организации не должны
приводить к полной замене БД.
К сожалению, не всегда возможно добиться наилучших результатов по всем этим
требованиям. Во многих случаях приходится идти на компромисс. Например,
экономичность часто находится в противоречии с гибкостью и доступностью БД.
Поэтому при разработке БД пытаются достичь возможного баланса между целями.
Логическое проектирование. На этом этапе завершается разработка внешних схем
БД. Требования различных пользователей и прикладных программ переводятся на язык
концептуальной схемы, используя REA модель и E-R диаграммы. Часто на этом этапе
выделяются подсистемы будущей БД, отвечающие за различные информационные
нужды. Например, подсистемы продаж, закупок, кадров, производства и т.д. Это
делается для удобства разработки и эксплуатации БД. Кроме того, на этом этапе
определяются первичные и вторичные ключи, разрабатывается справочник данных.
Физическое проектирование состоит в переводе концептуальной разработки в
физически существующие структуры хранения данных и работающих с ними
программ. Здесь концептуальная схема переводится во внутреннюю, создается
справочник данных, определяются способы физического хранения и доступа к БД, в
том числе принимаются решения об использовании индексов.
Внедрение и эксплуатация. Внедрение состоит в том, чтобы подготовить,
инициировать и запустить все процессы, связанные с эксплуатацией базы данных. Это
включает преобразование существующих данных в формат файлов новой базы данных,
разработку новых прикладных программ и модификацию существующих, обучение
пользователей, тестирование работы БД, переход на ее использование. Стадия
эксплуатации включает не просто реальное использование БД, но и наблюдение за ее
работой и выявлением неудовлетворенности пользователей, чтобы определить, что
необходимо усовершенствовать.
По различным причинам базы данных “стареют” и если простой модификации
становится недостаточно, то возникает потребность разработки новых принципов
работы. На этом жизненный цикл БД начинается сначала.
Роль экспертов организации. Эксперты организации должны быть вовлечены во
все стадии разработки БД. На стадии планирования они предоставляют информацию
для оценки возможностей и участвуют в принятии решения по этому вопросу. На
стадии определения требований и логического проектирования они участвуют в
определении информационных потребностей пользователей, разработке схем, словаря
данных, мер контроля. Во время внедрения - в тестировании БД и прикладных
программ. Наконец, при эксплуатации они используют БД и помогают принимать
решения по ее управлению.
КЛЮЧЕВЫЕ СЛОВА
База данных
Логическое представление данных
Физическое представление данных
Система управления базой данных (СУБД, или database management system - DBMS)
Авторизация пользователей
Справочник данных (словарь данных)
Схемы баз данных
Концептуальная схема
Внешняя схема
Внутренняя схема
Язык описания данных (ЯОД, или data definition language - DDL)
Язык управления данными (ЯУД, или data manipulation language - DML)
Язык описания запросов (ЯОЗ, или data query language - DQL)
Пользователи
Администратор данных
Администратор базы данных
Прикладные программисты
Модель данных
Реляционная модель данных
Первичный ключ
Правило целостности сущности
Внешний ключ
Правило ссылочной целостности
Нормализация
Избыточность данных
Аномалия обновления данных
Аномалия вставки записей
Аномалия удаления
Запросы
Проектирование
17
Выбор по условию
Объединение
Упорядочение
Группировка
Вложенные запросы
Текстовые и графические ЯОЗ
SQL - structured query language
Ключевые слова
SELECT, FROM, WHERE,
ORDER BY, ASCENDING, DESCENDING,
GROUP BY
QBE - query by example
Моделирование данных
REA модель данных
Ресурсы (Resources), События (Events), Участники (Agents)
E-R диаграммы (Entity-Relationship)
Характер отношений
Разработка E-R диаграммы
Выявление и изображение сущностей и отношений
Определение характера отношений
Применение модели
Создание таблиц
Определение атрибутов
Реализация отношений
Разработка баз данных
Планирование
Определение требований
Полнота, Адекватность, Актуальность, Точность, Доступность,
Эффективность, Экономичность, Безопасность, Гибкость
Логическое и физическое проектирование
Внедрение и эксплуатация
Роль экспертов организации