microbik.ru
1

Базы данных. Основные определения


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

Расширение набора автоматизированных функций управления привело к использованию разными структурами управления одних и тех же данных. Хранение нескольких электронных версий одних и тех же сведений приводило помимо дублирования к появлению и накоплению противоречий в разных версиях. Решением этой проблемы стало совместное использование разными пользователями одной и той же коллекции данных – базы данных. База данных (БД) - поименованная, целостная, единая система данных, организованная по определенным правилам, которые предусматривают общие принципы описания, хранения и обработки данных (Отраслевой стандарт “Информационные технологии в высшей школе. Термины и определения. ОСТ ВШ 01.002-95”. М., 1995 г., 24 с.).

Технологически выгодно все операции в БД передать специальной сетевой программе. Такую программу называют системой управления базами данных (СУБД). СУБД – это специальная программа (комплекс программ), которая обеспечивает хранение и доступ к данным. СУБД реализует общие принципы описания данных в виде ЯОД - языка описания данных (DDL - Data Definition Language) и принципы обработки данных в виде ЯМД - языка манипулирования данными (DML - Data Manipulation Language).

Для достижения независимости данных и программ выделяют три вида представления данных (см. Рис. 1):

  • представление пользователя (или внешняя модель или подсхема),

  • логическое описание (или схема или логическая БД),

  • внутреннее описание (или физическая БД).

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

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

В проектировании информационного обеспечения можно выделить

  1. Инфологическое проектирование - решение вопросов, связанных со смысловым содержанием данных:

  • о каких объектах и явлениях следует накапливать информацию;

  • какие их характеристики и взаимосвязи будут учитываться.

2. Даталогическое проектирование - решение вопросов связанных с представлением данных:

  • типы и форматы данных;

  • методы преобразования и смысловой интерпретации данных.







интерфейс

пользователя


интерфейс

логических

записей


интерфейс

физических

записей


Рис. 1. Представления данных.


^

Инфологическое проектирование. Модель "Сущность-связь"


Проектирование начинается с определения предметной области – части реально существующего мира, о которой необходимо накапливать информацию. Инструментом инфологического проектирования является модель "Сущность-связь". Она дает представление предметной области в виде множества сущностей и связей между ними. Это представление отражается в виде диаграмм "сущность-связь" (Entity-Relationship Diagram - ERD).

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

  • роли (люди, организации),

  • реальные предметы,

  • события (договора, поставки, оплаты),

  • расположения.

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


продает

покупает

^

Продавец


0:

Продажа

Покупатель


0:

1:1

1:1


0:


включает


1:1

Товар




Рис. 2. Модель «Сущность-связь» для торговых операций.
Все связи стараются свести к бинарному случаю – когда сущности связаны попарно. По количеству экземпляров сущностей, которые могут быть связаны, различают связи «один к одному», «один ко многим» и «многие ко многим». Эта характеристика связи детализируется следующим образом: участие каждой сущности в связи характеризуется двумя числами: ординальное число указывает минимальное количество сущностей в связи, кардинальное - максимальное. Например, для связи «включает» продаж и товаров установлено, что продажа включает один и только один товар, а товар включается в ноль или несколько продаж.

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

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

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

Сущности могут быть связаны несколькими связями. Например, сущность «Валюта» может быть связана с сущностью «Обмен» двумя связями: «продается» и «покупается».

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





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

Рекомендуется следующая последовательность построения модели "Сущность - связь":

  1. Идентификация сущностей. Для идентификации полезными оказываются следующие приемы:

  • При интервьюировании пользователей выделяйте ключевые слова.

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

  • Изучайте формы документов.

  • Исследуйте уже созданные и применяемы ИС.

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

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

  2. Описание каждой сущности набором атрибутов.

  3. Выбор идентификаторов и первичных ключей.

  4. Черновой набросок диаграммы.

  5. Формулировка и запись бизнес - правил, сопровождающих добавление, корректировку, удаление данных.

Модель данных существует и изменяется на всех этапах существования ИС.

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

При проектировании подсистем выделяются соответствующие модели данных подсистем. На этапе конструирования разрабатывается модель "сущность-связь" подсистемы.

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

  1. Установление идентичности. Два элемента идентичны, если они имеют одинаковое смысловое значение.

  2. Агрегация - объединение связанных элементов модели в один сложный (адрес, банковские реквизиты).

  3. Обобщение - разбиение множества сущностей на классы эквивалентности и введение сущностей соответствующих понятию класса. Создание таким образом иерархической структуры сущностей.

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


Первый пользователь Второй пользователь





Рис. 4. Объединение представлений пользователей.
Анализ событий (Event Analysis)


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

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

1-й шаг. Идентификация событий для независимых сущностей. Результатом идентификации является таблица, состоящая из следующих колонок:

  • сущность,

  • краткое описание события,

  • имя события,

  • тип действия: добавление, чтение, изменение или удаление данных,

  • условия выполнения действия.

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

Условия можно разбить на два класса:

  • вытекающие из экономической практики (известны пользователям),

  • обусловленные связями структур данных (определяются системными аналитиками): оцениваются связи двух сущностей - выделяется независимая, родительская сущность и зависимая сущность-потомок. До добавления потомка должен существовать родитель. Удаление родителя возможно, если у него нет потомков. Изменение атрибутов связи "родитель - потомок" либо не допустимо, либо выполняется синхронно.

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

Затем выполняется идентификация событий для зависимых сущностей.

3-й шаг. Консолидация общих событий. Проверяются таблица сущности – события - выделяются одинаково названные разные сущности и по разному названные одинаковые событий. Реорганизация таблицы - для каждого события указываются сущности и действия.

По результатам построения модели данных и анализа событий пересматривается описание потоков данных. При этом возможно:

  • добавление входных данных для проверки условий (например, на существование родителя);

  • добавление атрибутов;

  • добавление выходных данных;

  • добавление новых операций (например, проверки).

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