Концепция в общем смысле представляет некоторую систему взглядов на процесс или явление. Составными частями концепции являются совокупность принципов и методология. Под методологией понимается совокупность методов решения проблемы.
Принцип – правила, которыми следует руководствоваться в деятельности. Часто принципы формулируются в виде ограничений и требований, в частности, требований к базам данных.
Требования, предъявляемые к базам данных
С современных позиций следует порознь рассматривать требования, предъявляемые к транзакционным (операционным) базам данных и к хранилищам данных.
Первоначально перечислим основные требования, которые предъявляются к операционным базам данных, а следовательно, и к СУБД, на которых они строятся.
- 1. Простота обновления данных. Подоперацией обновления понимают добавления, удаления и изменения данных.
- 2. Высокое быстродействие (малое время отклика на запрос). Время отклика – промежуток времени от момента запроса к БД и фактическим получением данных. Похожим является термин время доступа – промежуток времени между выдачей команды записи (считывания) и фактическим получением данных. Под доступом понимается операция поиска, чтения данных или записи их.
- 3. Независимость данных.
- 4. Совместное использование данных многими пользователями.
- 5. Безопасность данных – защита данных от преднамеренного или непреднамеренного нарушения секретности, искажения или разрушения.
- 6. Стандартизация построения и эксплуатации БД (фактически СУБД).
- 7. Адекватность отображения данных соответствующей предметной области.
- 8. Дружелюбный интерфейс пользователя.
Важнейшими являются первые два противоречивых требования, повышение быстродействия требует упрощения структуры БД, что, в свою очередь, затрудняет процедуру обновления данных, увеличивает их избыточность (см. гл. 4).
Независимость данных – возможность изменения логической и физической структуры БД без изменения представлений пользователей. Независимость данных предполагает инвариантность к характеру хранения данных, программному обеспечению и техническим средствам. Она обеспечивает минимальные изменения структуры БД при изменениях стратегии доступа к данным и структуры самих исходных данных. Это достигается, как будет показано далее, "смешением" всех изменений на этапы концептуального и логического проектирования с минимальными изменениями на этапе физического проектирования |2).
Безопасность данных включает их целостность и защиту. Целостность данных – устойчивость хранимых данных к разрушению и уничтожению, связанных с неисправностями технических средств, системными ошибками и ошибочными действиями пользователей.
Она предполагает:
- отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;
- защиту от ошибок при обновлении БД;
- невозможность удаления порознь (каскадное удаление) связанных данных разных таблиц;
- неискажение данных при работе в многопользовательском режиме и в распределенных базах данных;
- сохранность данных при сбоях техники (восстановление данных).
Целостность обеспечивается триггерами целостности – специальными приложениями-программами, работающими при определенных условиях. Для некоторых СУБД (например, Access, Paradox) триггеры являются встроенными.
Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться:
- введением системы паролей;
- получением разрешений от администратора базы данных (АБД);
- запретом от АБД на доступ к данным;
- формированием видов – таблиц, производных от исходных и предназначенных конкретным пользователям.
Три последние процедуры легко выполняются в рамках языка структурированных запросов Structured Query Language – SQL, часто называемом SQL2.
Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент-сервер или сетевой вариант).
Перейдем к требованиям, предъявляемым к хранилищам данных, которые структурно являются продолжением операционных баз данных.
Пусть в базе данных имеются данные об успеваемости студентов третьего курса, при этом текущими являются пятый и шестой семестры. Данные за первые четыре семестра находятся (переданы) в хранилище данных (ХД), т. е. фактически в дополнительной, специфической базе данных. Необходимо запросить в хранилище фамилии студентов, которые первые четыре семестра учились только на отлично.
Иными словами, данные из операционной БД периодически передаются в электронный архив (в рассмотренном примере – данные за первые четыре семестра), а затем могут быть обработаны в соответствии с запросом пользователя.
Поскольку данные в хранилище практически не изменяются, а лишь добавляются, требование простоты обновления становится неактуальным. На первое место – в силу значительного объема данных в хранилище – выходит требование высокого быстродействия.
К хранилищам данных предъявляются следующие дополнительные требования :
- высокая производительность загрузки данных из операционных БД;
- возможность фильтрования, переформатирования, проверки целостности исходных данных, индексирования данных, обновления метаданных;
- повышенные требования к качеству исходных данных в части обеспечения их непротиворечивости, поскольку они могут быть получены из разных источников;
- высокая производительность запросов;
- обеспечение высокой размерности;
- одновременность доступа к ХД;
- наличие средств администрирования.
Поддержка анализа данных соответствующими методами (инструментами).
Как отмечено в Э.Ф. Кодд на основе своего опыта предъявил следующие требования к системе OLAP.
- 1. Многомерное концептуальное представление данных.
- 2. Прозрачность технологии и источников данных.
- 3. Доступность к источникам данных при использовании различных моделей данных.
- 4. Неизменная производительность подготовки отчетов при росте объема, количества измерений, процедур обобщения данных.
- 5. Использование гибкой, адаптивной, масштабируемой архитектуры клиент-сервер.
- 6. Универсальность измерений (формулы и средства создания отчетов не должны быть привязаны к конкретным видам размерностей).
- 7. Динамическое управление разреженностью матриц (пустые значения NULL должны храниться эффективным образом).
- 8. Многопользовательская поддержка.
- 9. Неограниченные операционные связи между размерностями.
- 10. Поддержка интуитивно понятных манипуляций с данными.
- 11. Гибкость средств формирования отчетов.
- 12. Неограниченное число измерений и уровней обобщения.
Перечисленные требования отличны от требований к операционным БД, что вызнало появление специализированных БД – хранилищ данных.
Возможность изменения логической и физической структуры БД без изменения представлений пользователей.
Независимость данных предполагает инвариантность к характеру хранения данных, программному обеспечению и техническим средствам. Она обеспечивает минимальные изменения структуры БД при изменениях стратегии доступа к данным и структуры самих исходных данных. Это достигается, как будет показано далее, «смещением» всех изменений на этапы концептуального и логического проектирования с минимальными изменениями на этапе физического проектирования .
Безопасность данных включает их целостность и защиту.
Устойчивость хранимых данных к разрушению и уничтожению, связанных с неисправностями технических средств, системными ошибками и ошибочными действиями пользователей.
Она предполагает:
1) отсутствие неточно введенных данных или двух одинаковых записей об одном и том же факте;
2) защиту от ошибок при обновлении БД;
3) невозможность удаления (или каскадное удаление) связанных данных разных таблиц;
4) неискажение данных при работе в многопользовательском режиме и в распределенных базах данных;
5) сохранность данных при сбоях техники (восстановление данных).
Целостность обеспечивается триггерами целостности - специальными приложениями-программами, работающими при определенных условиях. Защита данных от несанкционированного доступа предполагает ограничение доступа к конфиденциальным данным и может достигаться:
1) введением системы паролей;
2) получением разрешений от администратора базы данных (АБД);
4) формирование видов - таблиц, производных от исходных и предназначенных конкретным пользователям.
Три последние процедуры легко выполняются в рамках языка структуризованных запросов Structured Query Language - SQL, часто называемого SQL2.
Стандартизация обеспечивает преемственность поколений СУБД, упрощает взаимодействие БД одного поколения СУБД с одинаковыми и различными моделями данных. Стандартизация (ANSI/SPARC) осуществлена в значительной степени в части интерфейса пользователя СУБД и языка SQL. Это позволило успешно решить задачу взаимодействия различных реляционных СУБД как с помощью языка SQL, так и с применением приложения Open DataBase Connection (ODBC). При этом может быть осуществлен как локальный, так и удаленный доступ к данным (технология клиент/сервер или сетевой вариант).
Концепция построения БД
Представляет интерес эволюция концепции баз данных .
Первоначально (начало 60-х годов) использовалась файловая система хранения. Для решения преимущественно инженерных задач, характеризующихся небольшим количеством данных и значительным объемом вычислений, данные хранились непосредственно в программе. Применялся последовательный способ организации данных, имелась их высокая избыточность, идентичность логической и физической структур и полная зависимость данных. С появлением экономико-управленческих задач (информационная система руководства - MIS), отличающихся большими объемами данных и малой долей вычислений, указанная организация данных оказалась неэффективной. Требовалось упорядочение данных, которое, как выяснилось, возможно было проводить по двум критериям: использование (информационные массивы); хранение (базы данных). Первоначально применяли информационные массивы, но вскоре стало ясно превосходство баз данных. Использование файлов для хранения только данных (рис. 2.1, а)
было предложено Мак Гри в 1959 году. Были разработаны методы доступа (в том числе произвольного) к таким файлам, при этом физическая и логическая структуры уже различались, а физическое расположение данных можно было менять без изменения логического представления.
В 1963 году С. Бахманом была построена первая промышленная база данных IDS с сетевой моделью данных, которая все еще характеризовалась избыточностью данных и их использованием только для одного приложения. Доступ к данным осуществлялся с помощью соответствующего программного обеспечения. В 1969 году сформировалась группа, создавшая набор стандартов CODASYL для сетевой модели данных.
Фактически начала использоваться (рис. 2.1, б)
современная архитектура базы данных. Под архитектурой понимается разновидность (обобщение) структуры, в которой какой-либо элемент может быть заменен на другой элемент, характеристики входов и выходов которого идентичны первому элементу. Существенный скачок в развитии технологии баз данных дала предложенная М. Коддом в 1970 году парадигма реляционной модели данных. Под парадигмой
понимается научная теория, воплощенная в систему понятий, отражающих существенные черты действительности. Теперь логические структуры могли быть получены из одних и тех же физических данных, т.е. доступ к одним и тем же физическим данным мог осуществляться различными приложениями по разным путям. Стало возможным обеспечение целостности и независимости данных.
В конце 70-х годов появились современные СУБД, обеспечивающие физическую и логическую независимость, безопасность данных, обладающие развитыми языками БД. Последнее десятилетие характеризуется появлением распределенных и объектно-ориентированных баз данных, характеристики которых определяются приложениями средств автоматизации проектирования и интеллектуализации БД.
Прежде чем рассматривать процедуры работы с базой данных, дадим набор характеристик БД (рис. 2.2)
и пояснения к нему.
Существует два подхода к построению БД, базирующихся на двух подходах к созданию автоматизированной системы управления (АСУ).
Первый из них, широко использовавшийся в 80-е годы и потому получивший название классического (традиционного), связан с автоматизацией документооборота (совокупность документов, движущихся в процессе работы предприятия). Исходными и выходными координатами являлись документы, как это видно из примера 2.1.
Пример 2.1. Задача ставится следующим образом. Имеется система ручных документов, форма одного из которых показана в табл. 2.1.
Таблица 2.1.
Данные о поставках
Необходимо с помощью БД получить - по регламенту или по запросу - информацию в виде другой системы документов, форма одного из которых приведена в табл. 2.2.Таблица 2.2.
Отчет о поставках за квартал
Использовался следующий тезис. Данные менее подвижны, чем алгоритмы, поэтому следует создать универсальную БД, которую затем можно использовать для любого алгоритма. Однако вскоре выяснилось, что создание универсальной БД проблематично. Господствовавшая до недавнего времени концепция интеграции данных при резком увеличении их объема оказалась несостоятельной. Более того, стали появляться приложения (например, текстовые, графические редакторы), базирующиеся на широко используемых стандартных алгоритмах. Выявились стандартные алгоритмы и в управлении (бизнесе), как это следует из примера 2.2.
Пример 2.2. Рассмотрим стандартную процедуру использования банковской кредитной карточки. Покупатель-клиент выбирает товар в супермаркете и, подходя к кассе, предъявляет для оплаты кредитную карточку. Она опускается в специальный приемник, и данные с нее считываются и передаются в компьютер супермаркета. Этот компьютер связывается с компьютером банка, в котором хранятся деньги клиента. Данные из компьютера банка (относительно клиента) передаются в компьютер супермаркета. Если у клиента на счете в банке больше средств, чем стоимость отобранного им товара, то компьютер маркета разрешает отпустить товары. Одновременно он проводит пересчет средств на счете клиента, внося изменения в финансовые документы супермаркета, в счет клиента в банке и кредитную карточку. Кредитная карточка с измененными данными возвращается клиенту. Если средств у клиента недостаточно, кредитная карточка может быть возвращена клиенту и он не будет обслужен в супермаркете.
К 90-м годам сформировался второй, современный подход, связанный с автоматизацией управления. Он предполагает первоначальное выявление стандартных алгоритмов приложений (алгоритмов бизнеса в зарубежной терминологии), под которые определяются данные, а стало быть, и база данных. Объектно-ориентированное программирование только усилило значимость этого подхода. Состав БД для различных подходов представлен на рис. 2.3.
В работе БД возможен одно- и многопользовательский (несколько пользователей подключаются к одному компьютеру через разные порты) режимы.
Используют восходящее и нисходящее проектирование БД. Первое применяют в распределенных БД при интеграции спроектированных локальных баз данных, которые могут быть выполнены с использованием различных моделей данных. Более характерным для централизованных БД является нисходящее проектирование.
В последующих разделах первоначально будет рассмотрен классический подход для централизованных БД, а затем - современный. Распределенным БД посвящена часть III настоящей работы.
Работа с базами данных может быть представлена в виде схемы, показанной на рис. 2.4.
Из нее видно, что следует выделять методологию создания и методологию использования БД. Методология БД определяется в процедуре проектирования, но проявляется и в процедуре использования.
Методология проектирования баз данных
Существует много разновидностей методологии рассмотрения баз данных в классическом подходе , однако чаще всего придерживаются методологии ANSI/SPARC, схема которой представлена на рис. 2.5.
На рис. 2.5
показана совокупность процедур проектирования централизованной БД, которые можно объединить в четыре этапа.
На этапе формулирования и анализа требований устанавливаются цели организации, определяются требования к БД. Они состоят из общих требований, определенных в разделе 2.1 , и специфических требований. Для формирования специфических требований обычно используется методика интервьюирования персонала различных уровней управления. Все требования документируются в форме, доступной конечному пользователю и проектировщику БД.
Этап концептуального проектирования заключается в описании и синтезе информационных требований пользователей в первоначальный проект БД. Исходными данными могут быть совокупность документов пользователя (рис. 2.4) при классическом подходе или алгоритмы приложений (алгоритмы бизнеса) при современном подходе. Результатом этого этапа является высокоуровневое представление (в виде системы таблиц БД) информационных требований пользователей на основе различных подходов.
Сначала выбирается модель БД. Затем с помощью ЯОД создается структура БД, которая заполняется данными с помощью команд ЯМД, систем меню, экранных форм или в режиме просмотра таблиц БД. Здесь же обеспечивается защита и целостность (в том числе ссылочная) данных с помощью СУБД или путем построения триггеров.
В процессе логического проектирования высокоуровневое представление данных преобразуется в структуру используемой СУБД. Основной целью этапа является устранение избыточности данных с использованием специальных правил нормализации (рис. 2.4). Цель нормализации - минимизировать повторения данных и возможные структурные изменения БД при процедурах обновления. Это достигается разделением (декомпозицией) одной таблицы в две или несколько с последующим использованием при запросах операции навигации. Заметим, что навигационный поиск снижает быстродействие БД, т.е. увеличивает время отклика на запрос. Полученная логическая структура БД может быть оценена количественно с помощью различных характеристик (число обращений к логическим записям, объем данных в каждом приложении, общий объем данных). На основе этих оценок логическая структура может быть усовершенствована с целью достижения большей эффективности.
Специального обсуждения заслуживает процедура управления БД. Она наиболее проста в однопользовательском режиме. В многопользовательском режиме и в распределенных БД процедура сильно усложняется. При одновременном доступе нескольких пользователей без принятия специальных мер возможно нарушение целостности. Для устранения этого явления используют систему транзакций и режим блокировки таблиц или отдельных записей.
Процесс изменения файла, записи или базы данных, вызванный передачей одного входного сообщения. Особенности блокирования и варианты блокировки далее будут рассмотрены отдельно.
На этапе физического проектирования решаются вопросы, связанные с производительностью системы, определяются структуры хранения данных и методы доступа.
Взаимодействие между этапами проектирования и словарной системой необходимо рассматривать отдельно. Процедуры проектирования могут использоваться независимо в случае отсутствия словарной системы. Сама словарная система может рассматриваться как элемент автоматизации проекти-рования.
Средства проектирования и оценочные критерии используются на всех стадиях разработки. В настоящее время неопределенность при выборе критериев является наиболее слабым местом в проектировании БД. Это связано с трудностью описания и идентификации большого числа альтернативных решений.
Проще обстоит дело при работе с количественными критериями, к которым относятся время ответа на запрос, стоимость модификации, стоимость памяти, время на создание, стоимость на реорганизацию. Затруднение может вызывать противоречие критериев друг другу.
В то же время существует много критериев оптимальности, являющихся неизмеримыми свойствами, трудно выразимыми в количественном представлении или в виде целевой функции.
К качественным критериям могут относиться гибкость, адаптивность, доступность для новых пользователей, совместимость с другими системами, возможность конвертирования в другую вычислительную среду, возможность восстановления, возможность распределения и расширения.
Процесс проектирования является длительным и трудоемким и обычно продолжается несколько месяцев. Основными ресурсами проектировщика БД являются его собственная интуиция и опыт, поэтому качество решения во многих случаях может оказаться низким.
Основными причинами низкой эффективности проектируемых БД могут быть:
недостаточно глубокий анализ требований (начальные этапы проектирования), включая их семантику и взаимосвязь данных;
большая длительность процесса структурирования, делающая этот процесс утомительным и трудно выполняемым при ручной обработке.
В этих условиях важное значение приобретают вопросы автоматизации разработки.
Методология использования баз данных
БД используются обычно не самостоятельно, а являются компонентой различных информационных систем: банков данных, информационно-поисковых и экспертных систем, систем автоматизированного проектирования, автоматизированных рабочих мест, автоматизированных систем управления.
В БД имеется три уровня представления данных (рис. 2.4): концептуальная, логическая и физическая базы данных.
В процедуре использования чаще всего имеют дело с логической и - значительно реже - с концептуальной и физической моделью.
Словарь данных представляет собой как бы внутреннюю БД, содержащую централизованные сведения о всех типах данных, их имена, структуру, а также информацию об их использовании. Преимущество словаря данных - в эффективном накоплении и управлении информационными ресурсами предметной области. Его применение позволяет уменьшить избыточность и противоречивость данных при их вводе, осуществить простое и эффективное управление при их модификации, упростить процедуру проектирования БД за счет централизации управления данными, установить связи с другими пользователями. Таким образом, словарь данных содержит обобщенное представление всех трех уровней: концептуального, логического и физического.
Правильно спроектированная БД должна удовлетворять следующим требованиям:
1. Минимальная избыточность. Непротиворечивость.
2. Целостность данных.
3. Независимость данных.
4. Возможность ведения (добавления и удаления) и актуализации (корректировки, модификации) данных.
5. Безопасность и секретность.
6. Высокая производительность. Минимальные затраты.
7. Соблюдение стандартов.
1. Минимальная избыточность означает то, что данные в БД не должны дублироваться. Избыточность данных, если она существует, влечет две опасности:
Неоправданно большой расход памяти и уменьшение времени отклика системы при обработке излишне больших объемов данных.
Нарушение непротиворечивости данных, т.е. возникновение такой ситуации, когда в различных местах машинной памяти хранятся противоречивые данные. Возникновение противоречивости чрезвычайно опасно для БД.
Противоречивость может возникнуть в результате корректировкиизбыточных данных . При внесении изменений в логическую запись может случиться так, что отдельные экземпляры этой записи, хранящиеся в различных местах машинной памяти, окажутся нескорректированы. Программисту приходится проявлять особое внимание к организации процесса корректировки избыточных данных и разрабатывать специальные программы, предотвращающие появление противоречивости.
Противоречивость может возникнуть и при корректировкенеизбыточных данных . Централизованное хранение данных является причиной высокой вероятности того, что двум или более пользователям одновременно понадобятся одни и те же данные. Если один из пользователей обращается к данным, а другой в то же время вносит в них изменения, будут получены противоречивые данные. Объясняется это тем, что процесс обновления данных требует определенного времени, в течение которого одни и те же данные оказываются на разных стадиях обновления. При обращении к таким данным параллельно работающих программ будут получены противоречивые сведения.
В СУБД существуют сложные механизмы блокирования обновляемых данных от доступа к ним других пользователей. Параллельные запросы к одним и тем же данным обычно выполняются последовательно.
В ряде СУБД есть средства, предотвращающие дублирование и возникновение противоречивости данных. В противном случае такие средства разрабатывает системный программист.
2. Целостность данных означает то, что в БД должны храниться только правильные данные, т.е. соблюдаются логические условия, в соответствии с которыми данные считаются правильными. Разрушение и искажение данных возможны в результате неосторожных действий пользователей, в результате ошибок в программах и сбоев оборудования.
Существуют специальные методы и приемы обеспечения целостности.
Для обеспечения целостности на данные, хранящиеся в БД, накладывают ограничения . При этом определяются условия, которым должны соответствовать значения данных. Например, один и тот же служащий не может иметь два различных года рождения и т.п.. Подобные ограничения называются законами БД . Выполнимость законов БД периодически проверяется СУБД.
Для предотвращения возможности ввода неправильных данных разрабатываются средства контроля правильности вводимых данных. Так, например, можно использовать процедуры, проверяющие принадлежность вводимых значений определенному диапазону допустимых значений. Например, количество рабочих дней ограничивается сверху количеством дней в текущем месяце.
Целостность данных может нарушиться при неудачном завершении транзакции. Транзакцией называется некоторая неделимая последовательность операций над данными, выполняемая по одному запросу к БД. Примером транзакции является операция перевода денег с одного счета на другой в банковской системе. Здесь необходимо последовательное выполнение нескольких операций. Деньги снимаются с одного счета, данные корректируются, затем деньги добавляются к другому счету и данные вновь корректируются. Если хотя бы одно из действий не выполняется успешно, результат транзакции окажется неверным. СУБД должна отслеживать ход выполнения транзакции от начала до ее завершения. Если по какой-то причине какая-либо из операций не выполнилась, то транзакция отменяется полностью. При этом выполняется "откат" путем отмены всех уже выполненных изменений.
В БД должны быть предусмотрены средства восстановления данных после программных сбоев и сбоев оборудования. Существуют программы создания резервных копий и специальные программы, которые автоматически фиксируют любые внесенные в БД изменения (создается файл корректур). Если текущая версии БД испорчена, то берется предыдущая версия, в нее вносятся изменения, зафиксированные в файле корректур, и текущее (актуальное) состояние БД восстанавливается.
Различные СУБД в той или иной мере располагают средствами обеспечения целостности данных. В противном случае такие средства разрабатываются системным программистом.
3. Независимость данных означает то, что прикладные программы не должны зависеть от хранимых данных, т.е. от способа хранения данных в физической памяти. Это позволяет добавлять в БД новые данные, изменять структуры хранения данных, создавать на БД новые приложения. Ранее созданные программы при этом не должны "чувствовать" эти изменения.
СУБД обычно обеспечивают это требование.
4. Структура БД должна позволять включать новые и удалять устаревшие данные, корректировать хранимые данные без разрушения логических связей, установленных в схеме БД. Для этого схема БД должна быть правильно разработана, а операции ведения БД не должны нарушать схему БД.
5. Безопасность и секретность означает защиту данных от несанкционированного доступа, преднамеренного и непреднамеренного разрушения данных, хищения данных. Система защиты БД призвана решать следующие задачи.
Идентификация пользователей. Данными, хранящимися в БД должны пользоваться только лица, имеющие на это право и подтвердившие свои полномочия. Наиболее распространенным способом решения этой задачи является система паролей.
Ограничение доступа к данным. Каждый пользователь должен работать только с теми данными, которые необходимы для решения его задач, остальные данные должны быть для него "невидимыми".
Каждому пользователю предоставляются определенные полномочия (привилегии) для работы с данными. Ему может быть предоставлено право только чтения из БД, право ввода в БД или право обновления и т.п. Все привилегии предоставляются только администратору БД.
Обеспечение секретности данных. Секретные данные необходимо защищать от доступа системой специальных, достаточно сложных паролей. Сильно уязвимые данные следует шифровать.
Средства защиты и обеспечения безопасности данных содержатся в СУБД или разрабатываются системным программистом.
6. Организация БД и методы доступа к данным должны обеспечивать высокую скорость обработки данных такую, чтобы пользователь мог работать с БД в диалоговом режиме. Стоимость обслуживания пользователей не должна быть высокой.
Возможность выполнения этих требований определяется рядом факторов: объемом хранимых данных, быстродействием техники, способом организации данных в БД и во многом зависит от решений, принимаемых разработчиками на этапе создания БД. Например, можно организовать способ размещения данных на носителе таким образом, что наиболее часто используемые данные хранятся на наиболее доступных участках внешней памяти.
7. Представление данных в БД, сопроводительная документация, способ взаимодействия пользователя с БД должны удовлетворять определенным стандартам. Стандарты могут быть корпоративными, ведомственными, промышленными, национальными и международными. Соблюдение стандартов совершенно необходимо для совместного использования данных и для организации обмена данными между отдельными системами. Например, без принятия определенных стандартов нельзя было бы организовать сеть Internet.
Требования к функциональным характеристикам
База данных должна обеспечить хранение данных о работе химчистки. В базу данных должны заноситься следующие сведения:
Виды услуг(Код вида услуг, Название, Тип, Стоимость).
Клиенты (Код клиента, Фамилия, Имя, Отчество, Признак постоянного клиента).
Услуги (Код услуги, Код вида услуги, Код клиента, Дата приема, Дата возврата).
Необходимо организовать автоматический расчет стоимости услуг с учетом скидок и надбавок, автоматическое занесение клиента в постоянные с третьего обращения.
Требования к составу и параметрам технических средств
Необходимый объём свободной оперативной памяти для работы программы не более 15 Mb, свободного места на диске для установки программы до 20 Mb, процессор Р400.
Требования к информационной и программной совместимости
База данных должна быть в формате сервера FireBird 2.5, на компьютере должна быть установлена утилита для работы с базами данных IB Expert (IB Expert работает под управлением операционной системы семейства Windows).
Требования к программной документации
Документация к программе должна быть оформлена согласно существующим ГОСТам и содержать следующие разделы:
1. Анализ предметной области
2. Техническое задание
3. Концептуальная модель данных
4. Логическая модель данных
5. Физическая модель данных
6. Вычисляемые поля, генераторы и триггеры
7. Программа и методика испытаний
8. Описание применения
9. Заключение
10. Список использованных источников
11. Текст SQL-скрипта
12. Диаграммы
13. Результаты испытаний
Стадии и этапы разработки
a) Анализ задания на проектирование
b) Разработка концептуальной модели данных
c) Разработка логической модели
d) Разработка физической модели
e) Создание вычисляемых полей, генераторов, триггеров
f) Внесение данных в базу и тестирование работы
g) Документирование согласно существующим ГОСТам
Порядок контроля и приёмки
Для контроля работы базы данных должен быть разработан тестовый набор данных, состоящий из списка клиентов, сведений о приеме вещей и видах работ в химчистке.
Необходимо вручную рассчитать стоимость услуг с учетом скидок и надбавок. Подготовленный список надо ввести в базу и сравнить результат работы с результатом, полученным путем ручного расчета. Необходимо проверить возможность редактирования и добавления данных, правильность работы генераторов и триггеров.
Концептуальная модель данных
Концептуальная модель данных отображает обобщающее представление о данных, не зависимое от типа выбранной СУБД. Она описывает то, какие данные хранятся в базе данных, а также связи, существующие между ними. Фактически это полное представление требований к данным со стороны организации, у которой работают пользователи.
Концептуальная модель данных состоит из сущностей со своими атрибутами и n-арных связей и используется как средство построения и представления информационных потребностей предприятия.
Проанализировав описание предметной области, выделим объекты, сведения о которых участвуют в описании. Как правило, они мало меняются с течением времени и не зависят от существования других объектов. Сущности изображаются на диаграмме «объект/отношение» в виде прямоугольников. К сущностям относятся объекты: «Клиенты», «Вид работ», «Услуги».
Для каждого объекта определяем ключевое свойство, которое в дальнейшем будет использоваться в качестве первичного ключа. Для сущностей выбраны ключевые свойства:
«Клиенты» – код клиента
«Услуги» – код услуги
«Вид работ» – код вида работы
Затем проставляем не ключевые свойства (атрибуты) для объектов.
Определенные сущности и атрибуты представлены в таблицах 1-3:
Таблица 1 Сущность Клиенты
Таблица 2 Сущность Виды работ
Объекты вступают между собой в некоторые смысловые отношения, отображаемые на диаграмме «объект/отношение» в виде овалов (связи). Овалы соединяются отрезками прямых с прямоугольниками, которые соответствуют объектам, участвующим в отношении:
1-М (один-ко-многим) – Услуги-Клиенты (Оказываются), Услуги-Вид работ (Относятся).
Степень участия связи «Оказываются» между сущностями Услуги и Клиенты неполная и имеет показатели кардинальности 1,1 и N,1 соответственно, так как клиентам услуги могут оказываться многократно, а одной записи об услуге соответствует только один клиент.
Степень участия связи «Относятся» между сущностями Услуги и Виды работ неполная и имеет показатели кардинальности 1,1 и N,1 соответственно, так как одни и те же виды работ могут оказываться многократно, а одной записи об услуге соответствует только один вид работ.
Концептуальная диаграмма представлена в приложении В, рисунок 1.
Проектирование базы данных – это процесс создания проекта базы данных, предназначенной для поддержки функционирования экономического объекта и способствующей достижению его целей. Оно представляет собой трудоемкий процесс, требующий совместных усилий аналитиков, проектировщиков и пользователей. При проектировании базы данных необходимо учитывать тот факт, что база данных должна удовлетворять комплексу требований.
Эти требования следующие.
1. Целостность базы данных. (Требование полноты и непротиворечивости данных).
2. Многократное использование данных.
3. Быстрый поиск и получение информации по запросам пользователей.
4. Простота обновления данных.
5. Уменьшение излишней избыточности данных.
6. Защита данных от несанкционированного доступа, от искажения и уничтожения.
Жизненный цикл базы данных (ЖЦБД) – это процесс проектирования, реализации и поддержки базы данных. ЖЦБД состоит из следующих семи этапов:
1) предварительное планирование;
2) проверка осуществимости;
3) определение требований;
4) концептуальное проектирование;
5) логическое проектирование;
6) физическое проектирование;
7) оценка работы и поддержка базы данных.
Опишем главные задачи каждого этапа.
1. Предварительное планирование базы данных. Это важный этап в процессе перехода от разрозненных к интегрированным данным. На этом этапе собирается информация об используемых и находящихся в процессе разработки прикладных программах и файлах, связанных с ними. Она помогает установить связи между текущими приложениями и то, как используется информация приложений. Кроме того, позволяет определить будущие требования к базе данных.
2. Проверка осуществимости. Она предполагает подготовку отчетов по трем вопросам:
1) есть ли технология – необходимое оборудование и программное обеспечение – для реализации запланированной базы данных? (технологическая осуществимость );
2) имеются ли персонал, средства и эксперты для успешного осуществления плана создания базы данных? (операционная осуществимость );
3) окупится ли запланированная база данных? (экономическая эффективность ).
3. Определение требований .На этом этапе определяются:
· цели базы данных;
· информационные потребности различных структурных подразделений и их руководителей;
· требования к оборудованию;
· требования к программному обеспечению.
4.Концептуальное проектирование. На этом этапе создаются подробные модели пользовательских представлений данных предметной области. Затем они интегрируются в концептуальную модель , которая фиксирует все элементы корпоративных данных, подлежащих загрузке в базу данных. Эту модель называют еще концептуальной схемой базы данных.
5.Логическое проектирование. На этом этапе осуществляется выбор типа модели данных. Концептуальная модель отображается в логическую модель , основанную уже на структурах, характерных для выбранной модели. Так, если выбрана реляционная модель, то разрабатываются структуры таблиц, определяются их ключи, устанавливается связь между таблицами, оптимизируется созданная модель базы данных (минимизируется избыточность данных). Наиболее распространенным методом при оптимизации является метод нормальных форм или, другими словами, нормализация данных
6.Физическое проектирование. На этом этапе предусматривается принятие разработчиком окончательного решения о способах реализации создаваемой базы данных. Логическая модель расширяется характеристиками, необходимыми для определения способов физического хранения базы данных, типа устройств для хранения, методов доступа к данным базы, требуемого объема памяти, правил сопровождения базы данных и др.
7.Оценка и поддержка базы данных. Оценка включает опрос пользователей на предмет выяснения, какие их информационные потребности остались неучтенными. При необходимости в спроектированную базу данных вносятся изменения. Пользователи обучаются работе с базой данных. По мере расширения и изменения потребностей бизнеса поддержка базы данных обеспечивается путем внесения изменений, добавления новых данных, разработки новых прикладных программ, работающих с базой данных.
15. Модель «сущность–связь»
Средством моделирования предметной области на этапе концептуального проектирования является модель «сущность–связь». Часто ее называют ER-моделью (Entity – сущность, Relation – связь). В ней моделирование структуры данных предметной области базируется на использовании графических средств – ER-диаграмм (диаграмм «сущность–связь»). В наглядном виде они представляют связи между сущностями.
Основные понятия ER-диаграммы – сущность, атрибут, связь .
Сущность – это некоторый объект реального мира, который может существовать независимо . Сущность имеет экземпляры , отличающиеся друг от друга значениями атрибутов и допускающие однозначную идентификацию.
Атрибут – это свойство сущности . Например, сущность КНИГА характеризуется такими атрибутами, как автор, наименование, цена, издательство, тираж, количество страниц. Конкретные книги являются экземплярами сущности КНИГА. Они отличаются значениями указанных атрибутов и однозначно идентифицируются атрибутом «наименование». Атрибут, который уникальным образом идентифицирует экземпляры сущности, называется ключом . Может быть составной ключ, представляющий комбинацию нескольких атрибутов.
Предположим, что проектируется база данных, предназначенная для хранения информации о деятельности некоторой фирмы. Эта фирма имеет филиалы. Филиалы управляются менеджерами. Клиенты делают в филиалах заказы. Филиалы обрабатывают эти заказы. Описываемую предметную область назовем ФИРМА. В ней могут быть выделены четыре сущности: филиал, менеджер, заказ, клиент.
На ER-диаграмме сущность изображается прямоугольником, в котором указывается ее имя. Например,
|
В реальном мире существуют связи между сущностями. Связь представляет взаимодействие между сущностями. Она характеризуется мощностью , которая показывает, сколько сущностей участвует в связи. Связь между двумя сущностями называется бинарной .
В рассматриваемой предметной области ФИРМА можно выделить три связи:
1. МЕНЕДЖЕР – УПРАВЛЯЕТ – ФИЛИАЛ
2. ФИЛИАЛ – ОБРАБАТЫВАЕТ – ЗАКАЗ
3. КЛИЕНТ – ДЕЛАЕТ – ЗАКАЗ
На ER-диаграмме связь изображается ромбом.
Например,
Важной характеристикой связи является тип связи (кардинальность ).
Рассмотрим типы выше указанных связей 1–3.
Так как менеджер управляет только одним филиалом, то каждый экземпляр сущности МЕНЕДЖЕР может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ. В этом случае связь 1 имеет тип «один-к-одному» (1:1). На рис. 15.1 представлена ER-диаграмма для связи типа 1:1.
Так как филиал обрабатывает несколько заказов, а заказ обрабатывается только одним филиалом, то каждый экземпляр сущности ФИЛИАЛ может быть связан более чем с одним экземпляром сущности ЗАКАЗ, а каждый экземпляр сущности ЗАКАЗ может быть связан не более чем с одним экземпляром сущности ФИЛИАЛ.
В этом случае связь 2 имеет тип «один-ко-многим» (1:М). На рис. 15.2 представлена ER-диаграмма для связи типа 1:М.
Так как заказ могут делать несколько клиентов и клиент может иметь несколько заказов, то каждый экземпляр сущности ЗАКАЗ может быть связан с несколькими экземплярами сущности КЛИЕНТ и каждый экземпляр сущности КЛИЕНТ может быть связан с несколькими экземплярами сущности ЗАКАЗ. В этом случае связь 3 имеет тип «многие-ко-многим» (М:N). На рис. 10.3 представлена ER-диаграмма для связи типа М:N.
Рассмотрим понятие класс принадлежности сущности.
Если каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является обязательным. Этот факт отмечается на ER-диаграмме черным кружочком, помещенным в прямоугольник, смежный с прямоугольником сущности А.
Если не каждый экземпляр сущности А связан с экземпляром сущности В, то класс принадлежности сущности А является необязательным. Этот факт отмечается на ER-диаграмме черным кружочком, помещенным на линии связи возле прямоугольника сущности А.
В качестве примера на рис. 10.4 изображены возможные ER-диаграммы для связи М:N c учетом класса принадлежности сущности.
На ER-диаграмме 1 класс принадлежности обеих сущностей необязательный.
На ER-диаграмме 2 класс принадлежности сущности КЛИЕНТ обязательный, а сущности ЗАКАЗ необязательный.
На ER-диаграмме 3 класс принадлежности сущности КЛИЕНТ необязательный, а сущности ЗАКАЗ обязательный.
На ER-диаграмме 4 класс принадлежности обеих сущностей обязательный.
Предположим, что в рассматриваемой предметной области ФИРМА класс принадлежности всех четырех сущностей является обязательным. Тогда ER-модель предметной области ФИРМА будет иметь вид, представленный на рис. 10.5.
Каждая из четырех сущностей приведенной ER-модели может быть описана своим
набором атрибутов (рис. 15.6).
ER-модель в совокупности с наборами атрибутов сущностей может служить примером концептуальной модели предметной области или концептуальной схемы базы данных.
Рис . 15.6 . Наборы атрибутов сущностей предметной области ФИРМА
Примечание. Ключевые атрибуты выделены жирным шрифтом.
