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