2.Предметная область базы данных
реклама
1. Основные типы организации данных Известны три основных типа организации данных и связей между ними: иерархический (в виде дерева), сетевой и реляционный. Иерархическая БД. В иерархической БД существует упорядоченность элементов в записи, один элемент считается главным, остальные — подчиненными. Данные в записи упорядочены в определенную последовательность, как ступеньки лестницы, и поиск данных может осуществляться лишь последовательным "спуском" со ступеньки на ступеньку. Поиск какого-либо элемента данных в такой системе может оказаться довольно трудоемким из-за необходимости последовательно проходить несколько предшествующих иерархических уровней. Иерархическую БД образует каталог файлов, хранимых на диске; дерево каталогов, доступное для просмотра в Norton Commander, — наглядная демонстрация структуры такой БД и поиска в ней нужного элемента (при работе в операционной системе MS-DOS). Такой же БД является родовое генеалогическое дерево. Сетевая БД. Эта база данных отличается большей гибкостью, так как в ней существует возможность устанавливать дополнительно к вертикальным иерархическим связям горизонтальные связи. Это облегчает процесс поиска требуемых элементов данных, так как уже не требует обязательного прохождения всех предшествующих ступеней. Реляционная БД. Наиболее распространенным способом организации данных является третий, к которому можно свести как иерархический, так и сетевой — реляционный (англ. relation — отношение, связь). В реляционной БД под записью понимается строка прямоугольной таблицы. Элементы записи образуют столбцы этой таблицы (поля). Все элементы в столбце имеют одинаковый тип (числовой, символьный), а каждый столбец — неповторяющееся имя. Одинаковые строки в таблице отсутствуют. Преимущество таких БД— наглядность и понятность организации данных, скорость поиска нужной информации. Примером реляционной БД служит таблица на странице классного журнала, в которой записью является строка с данными о конкретном ученике, а имена полей (столбцов) указывают, какие данные о каждом ученике должны быть записаны в ячейках таблицы. 2.Предметная область базы данных Основным назначением информационных систем является оперативное обеспечение пользователя информацией о внешнем мире путем реализации вопросно-ответного отношения. Вопросно-ответные отношения, получая интерпретацию во внешнем мире (мире вне информационной системы), позволяют выделить для информационной системы определенный его фрагмент - предметную область, - который будет воплощен в автоматизированной информационной системе. Информация о внешнем мире представляется в информационной системе (ИС) в форме данных. Это ограничивает возможности смысловой интерпретации информации и конкретизирует семантику ее представления в ИС. Совокупность этих выделенных для ИС данных, связей между ними и операций над ними образует информационную ифункциональную модели предметной области, описывающие ее состояние с определенной точностью. Важно понимать, что информационная и функциональная модели предметной области создаются на этапе анализа требований к базе данных и не содержат предположений о технологии реализации базы данных. Они строятся независимо от выбираемой модели данных (сетевой, иерархической, реляционной, объектноориентированной, многомерной и т.д.), поддерживаемой СУБД, модели вычислений, программно-аппаратной платформы для базы данных. Информационная и функциональная модели предметной области являются входными данными для процесса проектирования базы данных. Поэтому проектировщик должен уметь правильно интерпретировать их в ходе решения своих проектных задач. Понятие предметной области базы данных является одним из базовых понятий информатики и не имеет точного определения. Его использование в контексте ИС предполагает существование устойчивой во времени соотнесенности между именами, понятиями и определенными реалиями внешнего мира, не зависящей от самой ИС и ее круга пользователей. Таким образом, введение в рассмотрение понятия предметной области базы данных ограничивает и делает обозримым пространство информационного поиска в ИС и позволяет выполнять запросы за конечное время. Совокупность реалий (объектов) внешнего мира - объектов, о которых можно задавать вопросы, - образует объектное ядро предметной области, которое имеет онтологический статус. Нельзя получить в ИС ответ на вопрос о том, что ей неизвестно. Термин объект является первичным, неопределяемым понятием. Синонимами термина "объект" являются "реалия, сущность, вещь". Однако термин сущность понимается нами несколько уже, как компонент модели предметной области, т.е. как уже выделенный на концептуальном уровне объект для базы данных. Таким образом, выделяемые в предметной области объекты превращаются аналитиками (а не проектировщиками базы данных) в сущности. Сущность предметной области является результатом абстрагирования реального объекта путем выделения и фиксации набора его свойств. Сущность является результатом абстрагирования реального объекта, т.е. в нашем контексте имеет гносеологический статус. Хотя далее в контексте сущность нередко отождествляется с объектом. На рис. 2.1 представлен один из подходов к классификации объектов предметной области. Рис. 2.1. Классификации объектов предметной области Примерами сущностей (с точки зрения ИС) или объектов (с точки зрения внешнего мира) являются отдельный студент, группа студентов, аудитория, время занятий, слова, числа, символы. Обычно считается, что быть объектом - это значит быть дискретным и различимым. Примеры "не-объектов" - это мир, время, смысл, хотя и такие категории могут сохраняться в базе данных. С объектами связано две проблемы: идентификация и адекватное описание. Для идентификации используют имя. При этом предполагается, что происходит отказ от его смысла, который присущ естественному языку. Используется только указательная функция имени. Имя - это прямой способ идентификации объекта. К косвенным способам идентификации объекта относят определение объекта через его свойства (характеристики или признаки). Объекты взаимодействуют между собой через свои свойства, что порождает ситуации. Ситуации - это взаимосвязи, выражающие взаимоотношения между объектами. Ситуации в предметной области описываются посредством высказываний о предметной области с использованием исчисления высказываний и исчисления предикатов, т.е. формальной, математической логики. Например, высказывание "Программист и менеджер есть служащие компании" описывает отношение включения. Таким образом, вся информация об объектах и сущностях предметной области описывается с помощью утверждений на естественном языке. Методы математической логики позволяют формализовать эти утверждения и представить их в виде, пригодном для анализа. Пример. Рассмотрим высказывание: Студент Иванов А.А, родился в 1982 году. Оно выражает следующие свойства объекта "Иванов А.А.": в явном виде - год рождения; в неявном - принадлежность к студентам. Первое свойство устанавливает связь между объектами "Иванов А.А." и "Год рождения", а второе - между объектами "Иванов А.А." и "Множество студентов". Формализация этого высказывания представляется как результат присваивания значений переменным, входящим в предикаты: РОДИЛСЯ (Иванов А.А., 1982) ЯВЛЯЕТСЯ СТУДЕНТОМ (Иванов А.А.) Отметим, что в семантике естественных языков ситуация и взаимосвязь считаются почти синонимами. Ситуация содержит высказывание об объектах предметной области, которому можно приписать некоторую оценку истинности и представить в виде предиката после введения переменных. Таким образом, совокупность высказываний о предметной области можно трактовать как определение информационного пространства для базы данных. На рис. 2.2 представлен один из подходов к классификации ситуаций в рамках предметной области. Рис. 2.2. Классификация ситуаций предметной области Различают статические и динамические ситуации. Примерами статических ситуаций являются такие ситуации, как иметь цвет, иметь возраст. Примерами динамических ситуаций являются такие ситуации, как создать утюг, выпечь хлеб. Обратите внимание на то, что ситуация также может представлять собой объект (см. рис. 2.1) и обладать свойствами. С другой стороны, приведенная классификация рассматривает свойства как специальный случай ситуаций. Подобная коллизия порождает неоднозначность при моделированиипредметной области базы данных. Поставим вопрос - что есть цвет автомобиля? Объект, свойство, ситуация? К обсуждению этого вопроса мы вернемся специально в следующей лекции. Приведенная классификация вводит в предметную область два важных аспекта пространство и время, причем время и как момент, и как интервал. Предметная область существует в пространстве и во времени, т.е. ей присущи, как и реальному миру, временные и пространственные отношения и связи. Следует отличать реальное время внешнего мира и его отражение в базе данных и в источниках информации. В базе данных взаимосвязи, зависящие от времени, фиксируются только после их регистрации в базе данных. Таким образом, предметная область в каждый конкретный момент времени представляет собой выделенную совокупность определенных объектов и ситуаций, называемую состоянием предметной области (или снимком). Введем определение предметной области. Определение. Предметная область - это целенаправленная первичная трансформация картины внешнего мира в некоторую умозрительную картину, определенная часть которой фиксируется в ИС в качестве алгоритмической модели фрагмента действительности. Понятие предметной области было введено в начале 80-х годов прошлого века, когда учеными в области ИС была осознана необходимость использовать семантические модели для представления информации в компьютерных системах. Так же как требования к компьютерной системе формируются средствами естественного языка, так и информация в компьютерных системах представляется средствами особого языка с определенной семантикой. Такой подход впервые был представлен П. Ченом в 1976 году. Одним из ключевых моментов создания ИС с целью автоматизации информационных процессов организации является всестороннее изучение объектов автоматизации, их свойств, взаимоотношений между этими объектами и представление полученной информации в виде информационной модели данных. Информационная модель данных предназначена для представления семантики предметной области в терминах субъективных средств описания - сущностей, атрибутов, идентификаторов сущностей, супертипов, подтипов и т.д. Информационная модель предметной области базы данных содержит следующие основные конструкции: диаграммы "сущность-связь" (Entity - Relationship Diagrams); определения сущностей; уникальные идентификаторы сущностей; определения атрибутов сущностей; отношения между сущностями; супертипы и подтипы. Внимание! Элементы информационной модели данных предметной области являются входными данными для решения задачи проектирования базы данных - создания логической модели данных. 3.Первичный ключ записи БД Вторичные ключи Перви́чный ключ (англ. primary key) — в реляционной модели данных один из потенциальных ключей отношения, выбранный в качестве основного ключа (или ключа по умолчанию). Если в отношении имеется единственный потенциальный ключ, он является и первичным ключом. Если потенциальных ключей несколько, один из них выбирается в качестве первичного, а другие называют «альтернативными». С точки зрения теории все потенциальные ключи отношения эквивалентны, то есть обладают одинаковыми свойствами уникальности и минимальности. Однако в качестве первичного обычно выбирается тот из потенциальных ключей, который наиболее удобен для тех или иных практических целей, например для создания внешних ключей в других отношениях либо для создания кластерного индекса. Поэтому в качестве первичного ключа как правило выбирают тот, который имеет наименьший размер (физического хранения) и/или включает наименьшее количество атрибутов. Исторически термин «первичный ключ» появился и стал использоваться существенно ранее термина «потенциальный ключ». Вследствие этого множество определений в реляционной теории были изначально сформулированы с упоминанием первичного (а не потенциального) ключа, например, определения нормальных форм. Так же термин «первичный ключ» вошёл в формулировку 12 правил Кодда как основной способ адресации любого значения отношения (таблицы) наряду с именем отношения (таблицы) и именем атрибута (столбца). Простые и составные ключи Если первичный ключ состоит из единственного атрибута, его называют простым ключом. Если первичный ключ состоит из двух и более атрибутов, его называют составным ключом. Так, имя, фамилия, отчество, номер паспорта, серия паспорта не могут быть первичными ключами по отдельности, так как могут оказаться одинаковыми у двух и более людей. Но не бывает двух личных документов одного типа с одинаковыми серией и номером. Поэтому в отношении, содержащем данные о людях, первичным ключом может быть подмножество атрибутов, состоящее из типа личного документа, его серии иномера. [править]Естественные и суррогатные ключи Первичный ключ может состоять из информационных полей таблицы (то есть полей, содержащих полезную информацию об описываемых объектах). Такой первичный ключ называют естественным ключом. Теоретически, естественный ключ всегда можно сформировать, в этом случае мы получим т. н. интеллектуальный ключ. На практике, однако, использование естественных ключей наталкивается на определённые сложности: Низкая эффективность — Естественный ключ может быть велик по размеру (особенно когда он составной), и его использование окажется технически неэффективным (ведь во всех таблицах, связанных с данной, понадобится создать поле того же размера, чтобы хранить ссылки). Необходимость каскадных изменений — При изменении значения поля, входящего в естественный ключ, оказывается необходимым изменить значение поля не только в данной таблице, но и во всех таблицах, связанных с данной, в противном случае все ссылки на данную запись окажутся некорректными. В сложных базах данных таких связанных таблиц может быть очень много, и всегда остаётся опасность упустить из виду какую-то из них. При добавлении новых связанных таблиц приходится добавлять согласующие изменения во все места программ, где правится исходная таблица. Несоответствие реальности — Уникальность естественного первичного ключа в реальных БД не всегда соблюдается. Допустим, например, что первичный ключ в таблице — данные личного документа. В такую таблицу окажется невозможным внести человека, о документах которого нет информации в момент добавления записи, а на практике такая необходимость может возникнуть. Повторяемость — При использовании естественного ключа, содержание может повторяться (так, как могут повторятся поля, из которых состоит ключ), что недопустимо в первичном ключе Вследствие этих и других соображений в практике проектирования БД чаще используют т. н. синтетические (суррогатные) ключи — искусственно созданные технические ключевые поля, не несущие информации об объектах. Ключ – это столбец (может быть несколько столбцов), добавляемый к таблице и позволяющий установить связь с записями в другой таблице. Существуют ключи двух типов: первичные и вторичные или внешние. Первичный ключ – это одно или несколько полей (столбцов), комбинация значений которых однозначно определяет каждую запись в таблице. Первичный ключ не допускает значений Null и всегда должен иметь уникальный индекс. Первичный ключ используется для связывания таблицы с внешними ключами в других таблицах. Внешний (вторичный) ключ - это одно или несколько полей (столбцов) в таблице, содержащих ссылку на поле или поля первичного ключа в другой таблице. Внешний ключ определяет способ объединения таблиц. Из двух логически связанных таблиц одну называют таблицей первичного ключа или главной таблицей, а другую таблицей вторичного (внешнего) ключа или подчиненной таблицей. СУБД позволяют сопоставить родственные записи из обеих таблиц и совместно вывести их в форме, отчете или запросе. 4. Модели данных В классической теории баз данных, модель данных есть формальная теория представления и обработки данных в системе управления базами данных (СУБД), которая включает, по меньшей мере, три аспекта: 1) аспект структуры: методы описания типов и логических структур данных в базе данных; 2) аспект манипуляции: методы манипулирования данными; 3) аспект целостности: методы описания и поддержки целостности базы данных. Аспект структуры определяет, что из себя логически представляет база данных, аспект целостности определяет средства описаний корректных состояний базы данных, аспект манипуляции определяет способы перехода между состояниями базы данных (то есть способы модификации данных) и способы извлечения данных из базы данных. Модель данных — это абстрактное, самодостаточное, логическое определение объектов, операторов и прочих элементов, в совокупности составляющих абстрактную машину доступа к данным, с которой взаимодействует пользователь. Эти объекты позволяют моделировать структуру данных, а операторы — поведение данных[1]. Каждая БД и СУБД строится на основе некоторой явной или неявной модели данных. Все СУБД, построенные на одной и той же модели данных, относят к одному типу. Например, основой реляционных СУБД является реляционная модель данных, сетевых СУБД — сетевая модель данных, иерархических СУБД — иерархическая модель данных и т.д. В литературе, статьях и в обиходной речи иногда встречается использование термина «модель данных» в смысле «схема базы данных» («модель базы данных»). Такое использование является неверным, на что указывают многие авторитетные специалисты, в том числе К. Дж. Дейт, М. Р. Когаловский, С. Д. Кузнецов. Модель данных естьтеория, или инструмент моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. По выражению К. Дейта соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке[1]. М. Р. Когаловский поясняет эволюцию смысла термина следующим образом. Первоначально понятие модели данных употреблялось как синоним структуры данных в конкретной базе данных. В процессе развития теории систем баз данных термин «модель данных» приобрел новое содержание. Возникла потребность в термине, который обозначал бы инструмент, а не результат моделирования, и воплощал бы, таким образом, множество всевозможных баз данных некоторого класса. Во второй половине 1970-х годов во многих публикациях, посвященных указанным проблемам, для этих целей стал использоваться все тот же термин «модель данных». В настоящее время в научной литературе термин «модель данных» трактуется в подавляющем большинстве случаев в инструментальном смысле (как инструмент моделирования)[2]. Тем не менее, длительное время термин «модель данных» использовался без формального определения. Одним из первых специалистов, который достаточно формально определил это понятие, был Э. Кодд. В статье «Модели данных в управлении базами данных»[3] он определил модель данных как комбинацию трех компонентов: 1. Коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели 2. Коллекции общих правил целостности, ограничивающих набор экземпляров тех типов объектов, которые законным образом могут появиться в любой такой базе данных 3. Коллекции операций, применимых к таким экземплярам объектов для выборки и других целей 5.Нормализация реляционных БД. Общий алгоритм нормализации Нормализация таблиц базы данных - первый шаг на пути проектирования структуры реляционной базы данных. Строго говоря, конечно, не самый первый - сначала надо решить, что же мы вообще будем хранить в базе, то есть определиться со структурой полей, их типами и размерностью, смыслом хранимой в них информации. Но это, как говорится, подразумевается по умолчанию:). Теория нормализации реляционных баз данных была разработана в конце 70-х годов 20 века. Согласно ей, выделяются шесть нормальных форм, пять из которых так и называются: первая, вторая, третья, четвертая, пятая нормальная форма, а также нормальная форма Бойса-Кодда, лежащая между третьей и четвертой. База данных считается нормализованной, если ее таблицы (по крайней мере, большинство таблиц) представлены как минимум в третьей нормальной форме. Часто многие таблицы нормализуются до четвертой нормальной формы, иногда, наоборот, производится денормализация. Использования таблиц в пятой нормальной форме (вернее сказать, сознательного приведения их к пятой нормальной форме) в реальных базах данных я лично не встречал. Главная цель нормализации базы данных - устранение избыточности и дублирования информации. В идеале при нормализации надо добиться, чтобы любое значение хранилось в базе в одном экземпляре, причем значение это не должно быть получено расчетным путем из других данных, хранящихся в базе. Наверно, нет смысла подробно рассматривать примеры нормализации таблиц. Такой информации и в Интернете, и в книгах более чем достаточно. Напомню только, каким основным требованиям должна удовлетворять каждая из нормальных форм. Первая нормальная форма Первая нормальная форма: запрещает повторяющиеся столбцы (содержащие одинаковую по смыслу информацию) запрещает множественные столбцы (содержащие значения типа списка и т.п.) требует определить первичный ключ для таблицы, то есть тот столбец или комбинацию столбцов, которые однозначно определяют каждую строку Вторая нормальная форма Вторая нормальная форма требует, чтобы неключевые столбцы таблиц зависили от первичного ключа в целом, но не от его части. Маленькая ремарочка: если таблица находится в первой нормальной форме и первичный ключ у нее состоит из одного столбца, то она автоматически находится и во второй нормальной форме. Третья нормальная форма Чтобы таблица находилась в третьей нормальной форме, необходимо, чтобы неключевые столбцы в ней не зависели от других неключевых столбцов, а зависели только от первичного ключа. Самая распространенная ситуация в данном контексте - это расчетные столбцы, значения которых можно получить путем каких-либо манипуляций с другими столбцами таблицы. Для приведения таблицы в третью нормальную форму такие столбцы из таблиц надо удалить. Нормальная форма Бойса-Кодда Нормальная форма Бойса-Кодда требует, чтобы в таблице был только один потенциальный первичный ключ. Чаще всего у таблиц, находящихся в третьей нормальной форме, так и бывает, но не всегда. Если обнаружился второй столбец (комбинация столбцов), позволяющий однозначно идентифицировать строку, то для приведения к нормальной форме Бойса-Кодда такие данные надо вынести в отдельную таблицу. Четвертая нормальная форма Для приведения таблицы, находящейся в нормальной форме Бойса-Кодда, к четвертой нормальной форме необходимо устранить имеющиеся в ней многозначные зависимости. То есть обеспечить, чтобы вставка / удаление любой строки таблицы не требовала бы вставки / удаления / модификации других строк этой же таблицы. Пятая нормальная форма Таблицу, находящуюся в четвертой нормальной форме и, казалось бы, уже нормализованную до предела, в некоторых случаях еще можно бывает разбить на три или более (но не на две!) таблиц, соединив которые, мы получим исходную таблицу. Получившиеся в результате такой, как правило, весьма искусственной, декомпозиции таблицы и называют находящимися в пятой нормальная форме. Формальное определение пятой нормальной формы таково: это форма, в которой устранены зависимости соединения. В большинстве случаев практической пользы от нормализации таблиц до пятой нормальной формы не наблюдается. Такая вот теория... Разработаны специальные формальные математические методы нормализации таблиц реляционных баз данных. На практике же толковый проектировщик баз данных, детально познакомившись с предметной областью, как правило, достаточно быстро набросает структуру, в которой большинство таблиц находятся в четвертой нормальной форме:). Краткие итоги. Зачем нужна нормализация. Главное, чего мы добьемся, проведя нормализацию базы данных - это устранение (или, по крайней мере, серьезное сокращение) избыточности, дублирования данных. Как следствие, значительно сокращается вероятность появления противоречивых данных, облегчается администрирование базы и обновление информации в ней, сокращается объем дискового пространства. Но не все так бело и пушисто. Зачастую, чтобы извлечь информацию из нормализованной базы данных, приходится конструировать очень сложные запросы, которые к тому же, бывает, работают довольно медленно - из-за, главным образом, большого количества соединений таблиц. Поэтому, чтобы увеличить скорость выборки данных и упростить программирование запросов, нередко приходится идти на выборочную денормализацию базы. Что это такое и как это делается - поговорим в следующей статье. 6. Инфологическая модель данных Инфологическая модель (информационно-логическая модель) — ориентированная на человека и не зависимая от типа СУБД модель предметной области, определяющая совокупности информационных объектов, их атрибутов и отношений между объектами, динамику изменений предметной области, а также характер информационных потребностей пользователей. Инфологическая модель предметной области может быть описана моделью "сущность—связь" (моделью Чена), в основе которой лежит деление реального мира на отдельные различимые сущности, находящиеся в определенных связях друг с другом, причем обе категории — сущность и связь полагаются первичными, неопределенными понятиями. Цель инфологического моделирования обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком (последний не может быть использован в чистом виде из-за сложности компьютерной обработки текстов и неоднозначности любого естественного языка). Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты). Основные понятия Сущность – любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Сущностями могут быть люди, места, самолеты, рейсы, вкус, цвет и т.д. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе. Например, типом сущности может быть ГОРОД, а экземпляром – Москва, Киев и т.д. Атрибут – поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей (например, ЦВЕТ может быть определен для многих сущностей: СОБАКА, АВТОМОБИЛЬ, ДЫМ и т.д.). Атрибуты используются для определения того, какая информация должна быть собрана о сущности. Примерами атрибутов для сущности АВТОМОБИЛЬ являются ТИП, МАРКА, НОМЕРНОЙ ЗНАК, ЦВЕТ и т.д. Здесь также существует различие между типом и экземпляром. Тип атрибута ЦВЕТ имеет много экземпляров или значений: Красный, Синий, Банановый, Белая ночь и т.д., однако каждому экземпляру сущности присваивается только одно значение атрибута. Абсолютное различие между типами сущностей и атрибутами отсутствует. Атрибут является таковым только в связи с типом сущности. В другом контексте атрибут может выступать как самостоятельная сущность. Например, для автомобильного завода цвет – это только атрибут продукта производства, а для лакокрасочной фабрики цвет – тип сущности. Ключ – минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся. Для сущности Расписание ключом является атрибут Номер_рейса или набор: Пункт_отправления, Время_вылета и Пункт_назначения (при условии, что из пункта в пункт вылетает в каждый момент времени один самолет). Связь – ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных – это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей. Требования, предъявляемые к инфологической модели Адекватное, отображение предметной области Недопущение неоднозначной трактовки модели Четкое определение моделируемой предметной области (конечность модели) Легкая расширяемость, обеспечивающая ввод новых данных без изменения ранее определенных, то же относят и к удалению данных Возможность композиции и декомпозиции модели в связи с большой размерностью реальных инфологических моделей Легкое восприятие различными категориями пользователей; желательно, чтобы инфологическую модель строил (или хотя бы участвовал в ее создании) специалист, работающий в данной предметной области, а не только проектировщик систем машинной обработки данных Применимость языка спецификаций модели как при ручном, так и при автоматизированном проектировании информационных систем Компоненты инфологической модели Описание объектов и связей между ними, называемой ER-моделью (расшифровывается как модель "Сущность-связь") Описание информационных потребностей пользователей Алгоритмические связи атрибутов Лингвистические отношения, обусловленные особенностями обображения предметной области в языковой среде Ограничения целостности Построение модели "Объект - свойтво - отношение" Классы объектов В предметной области в процессе ее обследования и анализа выделяют классы объектов. Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств. Например, если в качестве предметной области рассмотреть вуз, то в ней можно выделить следующие классы объектов: учащиеся, преподаватели, аудитории и т. д. Объекты могут быть реальными, как названные выше, а могут быть и абстрактными, как, например, предметы, которые изучают студенты. При отражении в информационной системе каждый объект представляется своим идентификатором, который отличает один объект класса от другого, а каждый класс объектов представляется именем этого класса. Так, для объектов класса «ИЗУЧАЕМЫЕ ПРЕДМЕТЫ» идентификатором каждого объекта будет «НАЗВАНИЕ ПРЕДМЕТА». Идентификатор должен быть уникальным. Каждый объект обладает определенным набором свойств. Для объектов одного класса набор этих свойств одинаков, а их значения, естественно, могут различаться. Например, для объектов класса «СТУДЕНТ» таким набором свойств, описывающим объекты класса, может быть «ГОД РОЖДЕНИЯ», «ПОЛ» и др. При описании предметной области надо изобразить каждый из существующих классов объектов и набор свойств, фиксируемый для объектов данного класса. Будем использовать для отображения объектов и их свойств следующие обозначения. Каждому классу объектов в инфологической модели присваивается уникальное имя. Именем класса объектов является грамматический оборот существительного (существительное, у которого могут быть прилагательные и предлоги). Если имя состоит из нескольких слов, то желательно, чтобы первым стояло существительное. Существительное должно употребляться в единствен ном, а не во множественном числе. Поэтому для рассмотренного выше класса объектов «ИЗУЧАЕМЫЕ ДИСЦИПЛИНЫ» лучше дать имя «ДИСЦИПЛИНА ИЗУЧАЕМАЯ». Если в предметной области традиционно используются разные имена для обозначения какого-либо класса объектов (т. е. имеет место синонимия), то все они должны быть зафиксированы при описании системы, затем одно из них выбирается за основное, и только оно должно в дальнейшем использоваться в ИЛМ. Помимо имени класса объектов в ИЛМ может использоваться его короткое кодовое обозначение. При построении инфологической модели желательно дать словесную интерпретацию каждой сущности, особенно если возможно неоднозначное толкование понятия. Связи между объектом и его свойствами При описании предметной области надо отразить связи между объектом и характеризующими его свойствами. Это изображается просто в виде линии, соединяющей обозначение объекта и его свойств. Связь между объектом и его свойством может быть различной. Объект может обладать только одним значением какого-то свойства. Например, каждый человек может иметь только одну дату рождения. Назовем такие свойства единичными. Для других свойств возможно существование одновременно нескольких значений у одного объекта. Пусть, например, при описании «СОТРУДНИКА» фиксируется в качестве его свойства «ИНОСТРАННЫЙ ЯЗЫК», которым он владеет. Так как сотрудник может знать несколько иностранных языков, то такое свойство будем называть множественным. При изображении связи между объектом и его свойствами для единичных свойств будем использовать одинарную стрелку, а для множественных свойств — двойную. Кроме того, некоторые свойства являются постоянными, их значение не может измениться с течением времени. Назовем такие свойства статическими, а те свойства, значение которых может изменяться со временем, будем называть динамическими. Другой характеристикой связи между объектом и его свойством является признак того, присутствует ли это свойство у всех объектов данного класса либо отсутствует у некоторыми объектов. Например, для отдельных служащих может иметь место свойство «УЧЕНАЯ СТЕПЕНЬ», а другие объекты этого класса могут не обладать, указанным свойством. Назовем такие свойства условными. При изображении связи условного свойства с объектом будем использовать пунктирную линию, а для обозначения динамических и статических свойств будем использовать буквы D и S над соответствующей линией. Иногда в инфологической модели бывает полезно ввести понятие «составное свойство». Примерами таких свойств могут быть «АДРЕС», состоящий из «ГОРОДА», «УЛИЦЫ», «ДОМА» и «КВАРТИРЫ», и «ДАТА РОЖДЕНИЯ», состоящая из «ЧИСЛА», «МЕСЯЦА» и «ГОДА». Используем в ИЛМ для обозначения составного свойства квадрат, из которого исходят линии, соединяющие его с обозначениями составляющих его элементов. Связи между объектами Кроме связи между объектом и его свойствами, в инфологической модели фиксируются связи между объектами разных классов. Различают связи типа: «один к одному» (1:1): в каждый момент времени каждому представителю (экземпляру) сущности А соответствует 1 или 0 представителей сущности В: Студент может не "заработать" стипендию, получить обычную или одну из повышенных стипендий. «один ко многим» (1:М): одному представителю сущности А соответствуют 0, 1 или несколько представителей сущности В. Квартира может пустовать, в ней может жить один или несколько жильцов. «многие к одному» (М:1) «многие ко многим» (М: М) Иногда эти типы связей называются степенью связи. Кроме степени связи в инфологической модели для характеристики связи между разными сущностями надо указывать так называемый «класс принадлежности», который показывает, может ли отсутствовать связь объекта данного класса с каким-либо объектом другого класса. Класс принадлежности сущности должен быть либо обязательным, либо необязательным. Объясним сказанное на конкретных примерах. Как указывалось выше, инфологическая модель строится не для отдельного объекта, а отображает классы объектов и связи между ними. Соответствующая диаграмма, отображающая это, называется диаграммой ER-типа (такое название обусловлено тем, что по-английски слово «сущность» пишется «Entity», а связь — «Relationship»). Однако иногда, кроме диаграмм ER-типа, используются диаграммы ERэкземпляров. Предположим, что в инфологической модели отображается связь между двумя классами объектов: «ЛИЧНОСТЬ» и «ЯЗЫК ИНОСТРАННЫЙ». Предположим, что предметной областью является завод, некоторые сотрудники которого знают иностранный язык, но ни один из них не владеет более чем одним языком. Естественно, что имеется много языков, которыми не владеет ни один из сотрудников, а также что некоторые из сотрудников владеют одним и тем же иностранным языком. Предположим далее, что предметной областью является институт, а объект «ЛИЧНОСТЬ» отображает абитуриентов, поступающих в этот институт. Каждый из абитуриентов обязательно должен владеть каким-либо иностранным языком, но никто ни владеет более чем одним языком. Как в первом, • так и во втором рассмотренном случае между сущностями наблюдается отношение М:1. На диаграмме это отображено со стороны объекта «ЛИЧНОСТЬ» двойной стрелецкой, а со стороны объекта «ЯЗЫК ИНОСТРАННЫЙ» — одинарной стрелкой на линии, изображающей связь между данными сущностями. Разница в рассматриваемых ситуациях заключается в том, что в первом случае класс принадлежности является необязательным для обоих сущностей, а во втором — для сущности «ЛИЧНОСТЬ» класс принадлежности является обязательным. На диаграмме это отображено точкой в прямоугольнике, соответствующем объекту «ЛИЧНОСТЬ». Пусть предметная область будет та же, что и в предыдущем случае, но имеют место ситуации, что некоторые абитуриенты знают несколько иностранных языков. В этом случае связь между объектами будет иметь тип М: М. Предположим, что предметной областью является некоторый лингвистический институт, в котором каждый из сотрудников обязательно знает несколько иностранных языков, и по каждому из известных науке языков в этом институте имеется хотя бы один специалист, владеющий им. В этом случае связь между объектам» будет М : М, и класс принадлежности обоих сущностей является обязательным" . Простые и сложные объекты Объект называется простым, если он рассматривается как неделимый. Сложный объект представляет собой объединение других объектов, простых или сложных, также отображаемых в информационной системе. Понятие «простой» и «сложный» объект является относительным. В одном рассмотрении объект может считаться простым, а в другом этот же объект может рассматриваться как сложный. Например, объект «стул» в подсистеме учета материальных ценностей будет рассматриваться как простой объект, а для предприятия, производящего стулья, это будет составной объект (включающий «ножки», «спинку», «сиденье» и пр.). Выделяют несколько разновидностей сложных объектов: составные объекты, обобщенные объекты и агрегированные объекты. Составной объект соответствует отображению отношения «целое— часть». Примерами составных объектов являются УЗЛЫ — ДЕТАЛИ, КЛАСС —УЧЕНИКИ и т. п. Для отображения составных объектов в инфологической модели обычно не используются какиелибо специальные условные обозначения. Связь между составным и составляющими его объектами отображается так же, как это было описано выше. Причем характер связи тоже может быть разный: так, «ДЕТАЛИ» и «УЗЛЫ» связаны между собой отношением типа М: М, а «ГРУППА» и «СТУДЕНТЫ» — отношением 1 : М. Обобщенный объект отражает наличие связи «род — вид» между объектами предметной области. Например, объекты СТУДЕНТ, ШКОЛЬНИК, АСПИРАНТ, УЧАЩИЙСЯ ТЕХНИКУМА образуют обобщенный объект УЧАЩИЕСЯ. Объекты, составляющие обобщенный объект, называются его категориями. Как «родовой» объект, так и «видовые» объекты могут обладать определенным набором свойств. Причем наблюдается так называемое наследование свойств, т. е. «видовой» объект обладает всеми теми свойствами, которыми обладает «родовой» объект, плюс свойствами, присущими только объектам этого вида. Агрегированные объекты соответствуют обычно какому-либо процессу, в который оказываются «вовлеченными» другие объекты. Например, агрегированный объект «ПОСТАВКА» объединяет в себе объекты «ПОСТАВЩИК», который поставляет продукцию, «ПОТРЕБИТЕЛЬ», который получает эту продукцию, а также саму поставляемую «ПРОДУКЦИЮ». Своеобразным объектом является «ДАТА ПОСТАВКИ». Агрегированный объект может, так же как и простой объект, иметь характеризующие его свойства. В рассматриваемом примере таким свойством может быть размер поставки. 7.ER-модели Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entityrelationship diagram (ERD)) — модель данных, позволяющая описыватьконцептуальные схемы. Представляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных. ER-модель удобна при прототипировании (проектировании) информационных систем, баз данных, архитектур компьютерных приложений, и других систем (далее, моделей). С её помощью можно выделить ключевые сущности, присутствующие в модели, и обозначить отношения, которые могут устанавливаться между этими сущностями. ER-модель является одной из самых простых визуальных моделей данных (графических нотаций). Она позволяет обозначить структуру «крупными мазками», в общих чертах. Это общее описание структуры называется ER-диаграммой или онтологией выбранной предметной области (area of interest). На этапе перехода к реализации данной ER-диаграммы в виде реальной информационной системы или программы, происходит отображение ER-модели в более детальную модель данных реляционной (объектной, сетевой, логической, или др.) базы данных, которая называется даталогической моделью данных по отношению к исходной ER-диаграмме. 8.Язык манипулирования данными SQL Введение SQL является, прежде всего, информационно-логическим языком, предназначенным для описания хранимых данных, для извлечения хранимых данных и для модификации данных. SQL не является языком программирования. (Вместе с тем стандарт языка спецификацией SQL/PSM предусматривает возможность его процедурных расширений). Изначально, SQL был основным способом работы пользователя с базой данных и представлял собой небольшую совокупность команд (операторов) допускающих создание таблиц, добавление в таблицы новых записей, извлечение записей из таблиц (в соответствии с заданным условием), удаление записей и изменение структур таблиц. В связи с усложнением язык SQL стал более прикладным языком программирования, а пользователи получили возможность использовать визуальные построители запросов. Язык SQL имеет две составляющие: язык обращения с данными Data Manipulation Language (DML) и язык определения данных Data Definition Language (DDL). DML состоит из операторов, используемых для создания и получения данных. DDL состоит из операторов, используемых для создания объектов в базе данных и для установки свойств и значений атрибутов самой базы данных. DML и DDL Чем же отличаются эти две группы операторов? В то время, как операторы DML достаточно однотипны для различных реализаций SQL (что дает возможность каждому поставщику программной продукции вводить свои расширения), DDL имеет существенные различия для разных продуктов. Каждый поставщик системы управления базой данных на физическом уровне различным образом реализует реляционную модель и каждый поставщик DDL неизбежно отражает эти различия. Большинство поставщиков предоставляют графические инструменты для определения данных и многие, включая и Microsoft, не ограничивают вас использованием только SQL DDL. Например, Microsoft предоставляет поддержку двух стандартов определения данных: ADO и DAO. Мы уже успели рассмотреть основные операторы DML: SELECT, INSERT, UPDATE и DELETE. Базовыми же операторами SQL DDL являются CREATE, ALTER и DROP, каждый из которых имеет несколько вариаций для создания объектов различных типов. Язык определения данных (Data Definition Language) Не многие программисты создают базу данных программным путём, большинство из нас для этого используют некую визуальную среду наподобие MS Access для построения файла MDB. Но иногда нам всё таки приходится создавать и удалять базу данных, а так же объекты базы данных программным путём. Для этого используется наиболее распространённая на сегодняшний день технология Structured Query Language Data Definition Language (SQL DDL). Выраджения языка определения данных (DDL) это SQL выражения, которые поддерживают определения или объявления объектов базы данных (например, CREATE TABLE, DROP TABLE, CREATE INDEX либо подобные им). Давайте взглянем на простейший пример выражения CREATE TABLE: CREATE TABLE PhoneBook( Name TEXT(50) Tel TEXT(50)); Данное DDL выражение (для MS Access) в время выполнения создаст новую таблицу с названием PhoneBook. Таблица PhoneBook будет иметь два поля: Name и Tel. Оба поля имеют строковый тип (TEXT) и размер поля 50 символов. Язык манипулирования данными Язык манипулирования данными - командный язык, обеспечивающий выполнение основных операций по работе с данными: ввод, модификацию и выборку данных по запросам. К базовым средствам манипулирования данными языка SQL относятся "поисковые" варианты операторов UPDATE и DELETE. Эти варианты называются поисковыми, потому что при задании соответствующей операции задается логическое условие, налагаемое на строки адресуемой оператором таблицы, которые должны быть подвергнуты модификации или удалению. Кроме того, в такую категорию языковых средств входит оператор INSERT, позволяющий добавлять строки в существующие таблицы. 9. Диаграмма потоков данных Диаграммы потоков данных (Data Flow Diagrams — DFD) представляют собой иерархию функциональных процессов, связанных потоками данных. Цель такого представления — продемонстрировать, как каждый процесс преобразует свои входные данные в выходные, а также выявить отношения между этими процессами. Для построения DFD традиционно используются две различные нотации, соответствующие методам Йордона-ДеМарко и Гейна-Сэрсона. Эти нотации незначительно отличаются друг от друга графическим изображением символов (далее в примерах используется нотация Гейна-Сэрсона). В соответствии с данным методом модель системы определяется как иерархия диаграмм потоков данных, описывающих асинхронный процесс преобразования информации от ее ввода в систему до выдачи потребителю. Источники информации (внешние сущности) порождают информационные потоки (потоки данных), переносящие информацию к подсистемам или процессам. Те, в свою очередь, преобразуют информацию и порождают новые потоки, которые переносят информацию к другим процессам или подсистемам, накопителям данных или внешним сущностям — потребителям информации. Диаграммы верхних уровней иерархии (контекстные диаграммы) определяют основные процессы или подсистемы с внешними входами и выходами. Они детализируются при помощи диаграмм нижнего уровня. Такая декомпозиция продолжается, создавая многоуровневую иерархию диаграмм, до тех пор, пока не будет достигнут уровень декомпозиции, на котором детализировать процессы далее не имеет смысла. Состав диаграмм потоков данных Основными компонентами диаграмм потоков данных являются: • внешние сущности; • системы и подсистемы; • процессы; • накопители данных; • потоки данных. Внешняя сущность представляет собой материальный объект или физическое лицо, являющиеся источником или приемником информации, например, заказчики, персонал, поставщики, клиенты, склад. Определение некоторого объекта или системы в качестве внешней сущности указывает на то, что она находится за пределами границ анализируемой системы. В процессе анализа некоторые внешние сущности могут быть перенесены внутрь диаграммы анализируемой системы, если это необходимо, или, наоборот, часть процессов может быть вынесена за пределы диаграммы и представлена как внешняя сущность. Внешняя сущность обозначается квадратом (Рис. 1), расположенным над диаграммой и бросающим на нее тень для того, чтобы можно было выделить этот символ среди других обозначений. Рисунок 1. Графическое изображение внешней сущности При построении модели сложной системы она может быть представлена в самом общем виде на так называемой контекстной диаграмме в виде одной системы как единого целого, либо может быть декомпозирована на ряд подсистем. Подсистема (или система) на контекстной диаграмме изображается так, как она представлена на Рис. 2. Рисунок 2. Подсистема по работе с физическими лицами (ГНИ — Государственная налоговая инспекция) Номер подсистемы служит для ее идентификации. В поле имени вводится наименование подсистемы в виде предложения с подлежащим и соответствующими определениями и дополнениями. Процесс представляет собой преобразование входных потоков данных в выходные в соответствии с определенным алгоритмом. Физически процесс может быть реализован различными способами: это может быть подразделение организации (отдел), выполняющее обработку входных документов и выпуск отчетов, программа, аппаратно реализованное логическое устройство и т.д. Процесс на диаграмме потоков данных изображается, как показано на Рис. 3. Рисунок 3. Графическое изображение процесса Номер процесса служит для его идентификации. В поле имени вводится наименование процесса в виде предложения с активным недвусмысленным глаголом в неопределенной форме (вычислить, рассчитать, проверить, определить, создать, получить), за которым следуют существительные в винительном падеже, например: "Ввести сведения о налогоплательщиках", "Выдать информацию о текущих расходах", "Проверить поступление денег". Информация в поле физической реализации показывает, какое подразделение организации, программа или аппаратное устройство выполняет данный процесс. Накопитель данных — это абстрактное устройство для хранения информации, которую можно в любой момент поместить в накопитель и через некоторое время извлечь, причем способы помещения и извлечения могут быть любыми. Накопитель данных может быть реализован физически в виде микрофиши, ящика в картотеке, таблицы в оперативной памяти, файла на магнитном носителе и т.д. Накопитель данных на диаграмме потоков данных изображается, как показано на Рис. 4. Рисунок 4. Графическое изображение накопителя данных Накопитель данных идентифицируется буквой "D" и произвольным числом. Имя накопителя выбирается из соображения наибольшей информативности для проектировщика. Накопитель данных в общем случае является прообразом будущей базы данных, и описание хранящихся в нем данных должно соответствовать модели данных. Поток данных определяет информацию, передаваемую через некоторое соединение от источника к приемнику. Реальный поток данных может быть информацией, передаваемой по кабелю между двумя устройствами, пересылаемыми по почте письмами, магнитными лентами или дискетами, переносимыми с одного компьютера на другой и т.д. Поток данных на диаграмме изображается линией, оканчивающейся стрелкой, которая показывает направление потока (Рис. 5). Каждый поток данных имеет имя, отражающее его содержание. Рисунок 5. Поток данных Построение иерархии диаграмм потоков данных Главная цель построения иерархии DFD заключается в том, чтобы сделать описание системы ясным и понятным на каждом уровне детализации, а также разбить его на части с точно определенными отношениями между ними. Для достижения этого целесообразно пользоваться следующими рекомендациями: • Размещать на каждой диаграмме от 3 до 6-7 процессов (аналогично SADT). Верхняя граница соответствует человеческим возможностям одновременного восприятия и понимания структуры сложной системы с множеством внутренних связей, нижняя граница выбрана по соображениям здравого смысла: нет необходимости детализировать процесс диаграммой, содержащей всего один или два процесса. • Не загромождать диаграммы несущественными на данном уровне деталями. • Декомпозицию потоков данных осуществлять параллельно с декомпозицией процессов. Эти две работы должны выполняться одновременно, а не одна после завершения другой. • Выбирать ясные, отражающие суть дела имена процессов и потоков, при этом стараться не использовать аббревиатуры. Первым шагом при построении иерархии DFD является построение контекстных диаграмм. Обычно при проектировании относительно простых систем строится единственная контекстная диаграмма со звездообразной топологией, в центре которой находится так называемый главный процесс, соединенный с приемниками и источниками информации, посредством которых с системой взаимодействуют пользователи и другие внешние системы. Перед построением контекстной DFD необходимо проанализировать внешние события (внешние сущности), оказывающие влияние на функционирование системы. Количество потоков на контекстной диаграмме должно быть по возможности небольшим, поскольку каждый из них может быть в дальнейшем разбит на несколько потоков на следующих уровнях диаграммы. Для проверки контекстной диаграммы можно составить список событий. Список событий должен состоять из описаний действий внешних сущностей (событий) и соответствующих реакций системы на события. Каждое событие должно соответствовать одному или более потокам данных: входные потоки интерпретируются как воздействия, а выходные потоки — как реакции системы на входные потоки. Для сложных систем (признаками сложности могут быть наличие большого количества внешних сущностей (десять и более), распределенная природа системы или ее многофункциональность) строится иерархия контекстных диаграмм. При этом контекстная диаграмма верхнего уровня содержит не единственный главный процесс, а набор подсистем, соединенных потоками данных. Контекстные диаграммы следующего уровня детализируют контекст и структуру подсистем. Для каждой подсистемы, присутствующей на контекстных диаграммах, выполняется ее детализация при помощи DFD. Это можно сделать путем построения диаграммы для каждого события. Каждое событие представляется в виде процесса с соответствующими входными и выходными потоками, накопителями данных, внешними сущностями и ссылки на другие процессы для описания связей между этим процессом и его окружением. Затем все построенные диаграммы сводятся в одну диаграмму нулевого уровня. Каждый процесс на DFD, в свою очередь, может быть детализирован при помощи DFD или (если процесс элементарный) спецификации. Спецификация процесса должна формулировать его основные функции таким образом, чтобы в дальнейшем специалист, выполняющий реализацию проекта, смог выполнить их или разработать соответствующую программу. Спецификация является конечной вершиной иерархии DFD. Решение о завершении детализации процесса и использовании спецификации принимается аналитиком исходя из следующих критериев: • наличия у процесса относительно небольшого количества входных и выходных потоков данных (2-3 потока); • возможности описания преобразования данных процессов в виде последовательного алгоритма; • выполнения процессом единственной логической функции преобразования входной информации в выходную; • возможности описания логики процесса при помощи спецификации небольшого объема (не более 2030 строк). Спецификации представляют собой описания алгоритмов задач, выполняемых процессами. Они содержат номер и/или имя процесса, списки входных и выходных данных и тело (описание) процесса, являющееся спецификацией алгоритма или операции, трансформирующей входные потоки данных в выходные. Языки спецификаций могут варьироваться от структурированного естественного языка или псевдокода до визуальных языков моделирования. Структурированный естественный язык применяется для понятного, достаточно строгого описания спецификаций процессов. При его использовании приняты следующие соглашения: • логика процесса выражается в виде комбинации последовательных конструкций, конструкций выбора и итераций; • глаголы должны быть активными, недвусмысленными и ориентированными на целевое действие (заполнить, вычислить, извлечь, а не модернизировать, обработать); • логика процесса должна быть выражена четко и недвусмысленно. При построении иерархии DFD переходить к детализации процессов следует только после определения содержания всех потоков и накопителей данных, которое описывается при помощи структур данных. Для каждого потока данных формируется список всех его элементов данных, затем элементы данных объединяются в структуры данных, соответствующие более крупным объектам данных (например, строкам документов или объектам предметной области). Каждый объект должен состоять из элементов, являющихся его атрибутами. Структуры данных могут содержать альтернативы, условные вхождения и итерации. Условное вхождение означает, что данный компонент может отсутствовать в структуре (например, структура "данные о страховании" для объекта "служащий"). Альтернатива означает, что в структуру может входить один из перечисленных элементов. Итерация означает вхождение любого числа элементов в указанном диапазоне (например, элемент "имя ребенка" для объекта "служащий"). Для каждого элемента данных может указываться его тип (непрерывные или дискретные данные). Для непрерывных данных могут указываться единица измерения, диапазон значений, точность представления и форма физического кодирования. Для дискретных данных может указываться таблица допустимых значений. После построения законченной модели системы ее необходимо верифицировать (проверить на полноту и согласованность). В полной модели все ее объекты (подсистемы, процессы, потоки данных) должны быть подробно описаны и детализированы. Выявленные недетализированные объекты следует детализировать, вернувшись на предыдущие шаги разработки. В согласованной модели для всех потоков данных и накопителей данных должно выполняться правило сохранения информации: все поступающие куда-либо данные должны быть считаны, а все считываемые данные должны быть записаны. При моделировании бизнес-процессов диаграммы потоков данных (DFD) используются для построения моделей "AS-IS" и "AS-TO-BE", отражая, таким образом, существующую и предлагаемую структуру бизнес-процессов организации и взаимодействие между ними. При этом описание используемых в организации данных на концептуальном уровне, независимом от средств реализации базы данных, выполняется с помощью модели "сущность-связь". Ниже перечислены основные виды и последовательность работ при построении бизнес-моделей с использованием методики Йордона: 1. Описание контекста процессов и построение начальной контекстной диаграммы. Начальная контекстная диаграмма потоков данных должна содержать нулевой процесс с именем, отражающим деятельность организации, внешние сущности, соединенные с нулевым процессом посредством потоков данных. Потоки данных соответствуют документам, запросам или сообщениям, которыми внешние сущности обмениваются с организацией. 2. Спецификация структур данных. пределяется состав потоков данных и готовится исходная информация для построения концептуальной модели данных в виде структур данных. Выделяются все структуры и элементы данных типа "итерация", "условное вхождение" и "альтернатива". Простые структуры и элементы данных объединяются в более крупные структуры. В результате для каждого потока данных должна быть сформирована иерархическая (древовидная) структура, конечные элементы (листья) которой являются элементами данных, узлы дерева являются структурами данных, а верхний узел дерева соответствует потоку данных в целом. 3. Построение начального варианта концептуальной модели данных. Для каждого класса объектов предметной области выделяется сущность. Устанавливаются связи между сущностями и определяются их характеристики. Строится диаграмма "сущность-связь" (без атрибутов сущностей). 4. Построение диаграмм потоков данных нулевого и последующих уровней. Для завершения анализа функционального аспекта деятельности организации детализируется (декомпозируется) начальная контекстная диаграмма. При этом можно построить диаграмму для каждого события, поставив ему в соответствие процесс и описав входные и выходные потоки, накопители данных, внешние сущности и ссылки на другие процессы для описания связей между этим процессом и его окружением. После этого все построенные диаграммы сводятся в одну диаграмму нулевого уровня. Процессы разделяются на группы, которые имеют много общего (работают с одинаковыми данными и/или имеют сходные функции). Они изображаются вместе на диаграмме более низкого (первого) уровня, а на диаграмме нулевого уровня объединяются в один процесс. Выделяются накопители данных, используемые процессами из одной группы. Декомпозируются сложные процессы и проверяется соответствие различных уровней модели процессов. Накопители данных описываются посредством структур данных, а процессы нижнего уровня — посредством спецификаций. 5. Уточнение концептуальной модели данных. Определяются атрибуты сущностей. Выделяются атрибуты-идентификаторы. Проверяются связи, выделяются (при необходимости) связи "супертип-подтип". Проверяется соответствие между описанием структур данных и концептуальной моделью (все элементы данных должны присутствовать на диаграмме в качестве атрибутов). 10.Создание логической модели данных Логическая модель данных описывает факты и объекты, подлежащие регистрации в будущей базе данных. Основными компонентами такой модели являются сущности, их атрибуты и связи между ними. Как правило, физическим аналогом сущности в будущей базе данных является таблица, а физическим аналогом атрибута — поле этой таблицы. С логической точки зрения сущность представляет собой совокупность однотипных объектов или фактов, называемых экземплярами этой сущности. Физическим аналогом экземпляра обычно является запись в таблице базы данных. Как и записи в таблице реляционной СУБД, экземпляры сущности должны быть уникальными, то есть полный набор значений их атрибутов не должен дублироваться. И так же, как и поля в таблице, атрибуты могут быть ключевыми и неключевыми. На этапе логического проектирования для каждого атрибута обычно определяется примерный тип данных (строковый, числовой, BLOB и др.). Конкретизация происходит на этапе физического проектирования, так как различные СУБД поддерживают разные типы данных и ограничения на их длину или точность. Связь с логической точки зрения представляет собой соотношение между сущностями, которое нередко может быть выражено обычными фразами, например: «Клиент размещает заказ» («A customer places an order» — этой фразой вполне можно описать связь, изображенную на рис. 1), где существительными являются названия связанных между собой сущностей. Подавляющее большинство средств проектирования данных позволяют создавать ER-диаграммы визуально, изображая сущности и соединяя их связями с помощью мыши. Интерфейс таких средств нередко настолько прост, что позволяет освоить логическое проектирование данных не только разработчику, но и пользователю-непрограммисту, если таковой участвует в проектировании данных как эксперт в предметной области. Отметим, что на этапе логического проектирования можно описать поведение СУБД при нарушении правил ссылочной целостности, определяемых данной связью (например, при удалении сведений о заказчике, разместившем хотя бы один заказ, для связи, изображенной на рис. 1). Для этого многие (но не все!) средства проектирования данных обладают языком шаблонов, не зависящим от СУБД, на котором можно описать алгоритм обработки подобной ситуации, например с помощью соответствующих триггеров или иных объектов базы данных, а также набором стандартных шаблонов, реализующих некоторые типовые алгоритмы подобной обработки (например, отказ от удаления с последующей генерацией диагностического сообщения, каскадное удаление дочерних записей и др.). В процессе создания физической модели (о ней будет рассказано чуть ниже) эти шаблоны преобразуются в код на процедурном расширении языка SQL, применяемом в конкретной СУБД. Ряд публикаций проводит градацию категорий логических моделей по степени детализации описания сущностей, атрибутов и связей. Модель, обсуждаемая с заказчиком, являющимся обычно экспертом в подлежащей автоматизации предметной области, а не программистом или аналитиком, должна содержать, например, основные сущности и связи, но не обязана иметь их детальную техническую проработку (в частности, описания алгоритмов обработки нарушений ссылочной целостности). В то же время модель, служащая основой технического задания на разработку клиентских приложений, обязана содержать детальное представление структуры данных, ключевых атрибутов, их текстовое описание, а также представлять сущности в нормализованном виде (иногда такая модель называется полной атрибутивной моделью). Иными словами, нормализация модели данных обычно происходит на этапе логического проектирования (подробнее о нормализации рассказано в первой статье данного цикла, опубликованной в КомпьютерПресс № 3’2000). Отметим, что логическая модель данных, как правило, не связана с конкретной СУБД и не учитывает технические особенности конкретных платформ, применяемых при ее последующей физической реализации. Или это: В настоящее время основным средством накопления и использования структурированной информации служат базы данных. Концептуальный выбор логической модели данных в принципе предопределяет уровень эффективности той или иной программной реализации базы данных. Различают четыре логические модели данных: иерархические; сетевые; реляционные; многомерные. С точки зрения структур данных, использующихся для связи между собой внутренних объектов базы, логические модели можно объединить в две группы: навигационные модели данных с адресными указателями на данные; ссылочная модель данных с именами (идентификаторами) данных. К навигационным моделям данных относятся иерархическая, сетевая и многомерная логические модели, к ссылочной модели данных – реляционная модель. Основным отличием базы данных от файловой системы является универсальность базы – т.е. независимость от какой-либо одной структуры описания предметного мира. Исторически первой стала применяться навигационная модель данных, основанная на многоуровневой структуре объектов, связанных адресными указателями по принципу «предок-потомок» в иерархию (у каждого потомка один предок) или сеть (у потомка может существовать любое число предков). Однако применение иерархической и сетевой разновидностей навигационной модели данных накладывало существенные ограничения на эффективность реализации основных операций (запись, чтение, изменение и удаление) над данными в базе: в случае иерархии чтение могло быть эффективно реализовано только в отношении одного типа атрибута элемента данных, лежащего в основе иерархии; в отношении остальных типов атрибутов необходимо было применять неэффективный метод полного перебора данных в базе; в случае сети эффективность чтения не зависела от выбора типа атрибута элемента данных, но при этом существенно замедлялась скорость выполнения записи, изменения и удаления данных из-за необходимости модификации многочисленных адресных указателей, образующих сетевую структуру. В 1970 году Э.Ф.Кодд теоретически обосновал, что более универсальным решением в области баз данных является ссылочная модель: "Реляционная модель предоставляет средства описания данных на основе только их естественной структуры, т.е. без потребности введения какой-либо дополнительной структуры для целей машинного представления" [1]. Первичной структурой хранения информации в реляционной модели данных служит двухмерный массив – реляционная таблица. Порядок расположения единичных записей – данных в реляционной таблице произволен, так же как и порядок расположения атрибутов в составе данных. Данные в разных реляционных таблицах связаны между собой ссылками на идентификаторы (внешние ключи). Это дает возможность с наибольшей скоростью выполнять операции записи, изменения и удаления данных. Однако теоретическая модель Э.Ф.Кодда обладает явной неполнотой – в связи с отсутствием в её составе какого-либо механизма поиска данных для целей последующего чтения, за исключением механизма, основанного на полном переборе данных в базе. При достаточно большом (или малом, с точки зрения современного состояния) количестве данных в реляционную базу в обязательном порядке включается тот или иной механизм поиска, т.е. дополнительная структура, отсутствие потребности в которой было декларировано Э.Ф.Коддом. Эффективность ссылочной модели данных Преимущество теоретической ссылочной модели перед навигационной моделью данных основано на двух постулатах: произвольном порядке расположения данных в реляционных таблицах и атрибутов в составе данных; логических связях реляционных таблиц между собой в отличие от физических адресных связей первичных структур хранения информации в навигационной модели. В отличие от теоретической, полная ссылочная модель данных, претендующая на статус универсальной, должна описывать как можно более широкий круг естественных структур данных. Большинство типов естественных структур данных представляет собой иерархические, древовидные структуры, включающие в свой состав множество групп и подгрупп характеристик, логически связанных между собой. Разрыв внутренних связей атрибутов в попытке обеспечить произвольный порядок их расположения приведет к полной неадекватности представления информации в базе данных относительно описываемой предметной области. Для преодоления этой проблемы в ссылочной модели применяют дезинтеграцию естественной структуры данных – нормализацию информации, т.е. представление данных единого типа в виде нескольких реляционных таблиц, количество типов атрибутов в каждой из которых в пределе стремится к единице. При увеличении числа реляционных таблиц прямо пропорционально возрастают издержки на дезинтеграцию (на этапе записи) и последующую интеграцию (на этапах чтения, изменения и удаления) данных. На практике уровень нормализации ограничивают 3-4 нормальной формой, что, в общем случае примерно соответствует кратности роста числа реляционных таблиц в базе. База данных по определению является хранилищем, а не могильником информации. Поэтому её неотъемлемой частью является тот или иной механизм поиска данных, ранее записанных в базу. Как показывает анализ современных реализаций систем управления базами данных ссылочная и навигационные модели обладают идентичными механизмами поиска, основанными на иерархических структурах: В-деревьях и В+-деревьях. Каждый экземпляр механизма поиска обслуживает один тип атрибута данных, являющегося ключом поиска. На каждую первичную структуру хранения данных может приходиться от одного до нескольких экземпляров механизма поиска. В-деревья состоят из узлов, связанных в иерархию так, что каждый более верхний узел связан с несколькими более нижними узлами, за исключением корневого узла, связанного только с узлами более нижнего уровня, и листовых узлов (листьев), связанных только с одним узлом более верхнего уровня. В каждом узле располагается набор атрибутов и, в случае реляционной базы, списки идентификаторов данных, в состав которых входят указанные атрибуты. Отдельный атрибут отражается только в одном из узлов дерева. Объем узла имеет переменный размер в связи с неограниченностью количества идентификаторов данных, в состав которых могут входить атрибуты, отраженные в узле. Для локализации места расположения идентификаторов данных применяют В+деревья, в составе которых отдельный атрибут отражается в нескольких узлах в направлении иерархической связи, ведущей к одному из листов дерева, где, кроме этого атрибута, отражается список связанных с ним идентификаторов данных [2]. В общем случае атрибут отражается в количестве узлов, равном половине от числа уровней В+-дерева. Выбор деревьев в качестве механизмов поиска был основан на стремлении минимизировать число обращений к энергонезависимому накопителю информации, обладающему на один-два порядка меньшим быстродействием по сравнению с оперативной памятью компьютера, на котором устанавливается система управления базой данных. В связи с возможностью неограниченного роста размера каждого из узлов В-дерева все они располагаются на энергонезависимом носителе информации, вынуждая обращаться к нему на этапах как записи, так и чтения данных. В В+-дереве информация переменного размера локализуется в листьях, которые размещаются на энергонезависимом носителе информации. Узлы, в которых отражается только заранее известное число атрибутов, могут быть размещены в оперативной памяти компьютера. На этапе записи одного атрибута количество обращений к энергонезависимому носителю информации составит половину от числа уровней дерева плюс одно обращение для записи элемента данных в реляционную таблицу, на этапе чтения поиск будет производиться только в оперативной памяти компьютера. При достаточно большом количестве данных в реляционной таблице число уровней В+-дерева может достигать 8–10 единиц. К сожалению, в случае реляционной базы данных этап чтения не ограничивается только использованием иерархического механизма поиска, поскольку в результате поиска будет найден всего лишь список идентификаторов данных, но не сами данные. Поиск в дихотомической форме (последовательном делении на две части) должен быть продолжен непосредственно в составе реляционной таблицы в колонке идентификаторов, по умолчанию упорядоченных по возрастанию. В процессе дихотомического поиска для каждого идентификатора в списке, соответствующего строго одному элементу данных, необходимо сделать как минимум четыре шага – чтение первого по порядку идентификатора, чтение последнего по порядку идентификатора, чтение идентификатора, расположенного в середине реляционной таблицы, чтение искомого идентификатора. Чем больше данных в реляционной таблице и чем больше идентификаторов в списке листа В+-дерева, тем большее количество шагов дихотомического поиска необходимо совершить. Эффективность навигационной модели данных В отличие от ссылочной, в навигационной модели данных в узлах иерархического механизма поиска достаточно расположить только атрибут, связанный лишь с одним адресным указателем на место расположения данных (в виде величины смещения в байтах от начала файла), записанных последними по порядку в первичную структуру хранения информации. В результате получается компактный иерархический механизм поиска предсказуемого размера, который может быть целиком размещен в оперативной памяти компьютера. Последние и предыдущие по порядку записи данные в первичной структуре хранения информации навигационной модели связаны между собой адресными указателями в список, аналогичный списку идентификаторов данных листа В+дерева ссылочной модели. Дополнительный поиск данных (адрес которых уже найден в узле дерева) в составе первичной структуры хранения информации не производится (на этапе записи) или производится с использованием списка данных подобно поиску с использованием списка идентификаторов в листе В+дерева (на этапе чтения). В случае применения навигационной модели данных обеспечивается только два обращения к энергонезависимому носителю информации на этапе записи (сохранение атрибута в составе узла и сохранение данных в составе первичной структуры хранения) и несколько обращений на этапе чтения (в составе первичной структуры хранения). С учетом нормализации реляционных данных и сохранения естественной структуры иерархических данных соотношение производительности ссылочной и навигационной баз данных на этапах записи и чтения составит: K произв. = M ссыл. / M навиг. + N ссыл. / N навиг., где M – количество первичных структур хранения информации, а N – количество обращений к энергонезависимому носителю информации. Учитывая приведенные выше оценки, можно видеть, что разрыв в производительности ссылочной и реляционной баз данных на этапах записи и чтения данных может составить от 12 до 15 раз. Единственной отрицательной стороной классической навигационной модели данных является более низкая скорость выполнения операций изменения и удаления данных по сравнению со ссылочной моделью. Многочисленные адресные указатели соединяют не только узлы экземпляра дерева поиска и данные в составе первичной структуры хранения информации, относящейся к выбранному экземпляру дерева поиска (в этом плане ссылочная и навигационная модели принципиально соответствуют друг другу), но и данные в составе различных первичных структур хранения информации, логически связанных между собой в качестве объектов схемы базы данных. Любая модификация данных в составе навигационной базы влечет за собой массовый пересчет адресных указателей в составе всех или большей части первичных структур хранения информации. В этом случае производительность навигационной базы данных падает относительно производительности ссылочной базы данных пропорционально количеству первичных структур хранения информации, затронутых операциями изменения или удаления данных. Устранение адресных указателей из логических связей объектов схемы базы данных позволит ликвидировать различия в производительности навигационных и ссылочных баз на этапах модификации данных. В связи с этим предлагается дополнить навигационную модель одним принципиальным заимствованием из ссылочной модели данных (подобно обратному заимствованию иерархической структуры поиска), а именно, использовать внешние ключи – идентификаторы в одной первичной структуре хранения информации для поиска данных, расположенных в другой структуре хранения информации. Предлагаемое решение обеспечит независимую модификацию данных, связанных в списки, в каждой отдельной первичной структуре хранения информации навигационной базы. Затраты времени при этом будут вполне сопоставимы с модификацией списков идентификаторов в листе B+-дерева ссылочной базы данных. Конечная цель развития логических моделей данных Введение в навигационную модель данных механизма ссылок в виде внешних ключей позволит гибко (без привязки к направленности адресных указателей в логических связях) формировать ключ поиска при сложных запросах к навигационной базе данных – обход объектов схемы можно будет производить в произвольном порядке, аналогично обходу объектов схемы ссылочной базы данных. Исторически последней логической моделью данных, использованной на практике, является многомерная модель, отражающая в полной мере естественную структуру данных из любой предметной области, в отличие от иерархической, сетевой и реляционной моделей, ограниченных в своих возможностях по определению. Классическая многомерная модель сочетает в себе первичную структуру хранения информации и механизм поиска. В качестве первичных структур хранения информации используются ячейки многомерного пространства (при едином базисе измерений) или гиперкубы – области ячеек многомерного пространства (при множественном базисе измерений). Второй (поликубический) вариант получил наибольшее распространение в силу удобства оперирования отдельными подмножествами многомерной базы данных, в том числе, при обращении к энергонезависимому носителю информации. Механизм поиска основан на перемещении вдоль оси каждого измерения на заранее рассчитанное (с помощью формата записи) расстояние вплоть до координаты измерения, соответствующей атрибуту элемента данных. В оперативной памяти компьютера для каждого базиса измерений достаточно поддерживать представление осей измерений в виде таблиц уникальных значений атрибутов, упорядоченных по возрастанию или убыванию. На пересечении осей измерений находится ячейка многомерного пространства, содержащая элемент данных или указатель на элемент данных, расположенный на энергонезависимом носителе информации. Единственный недостаток классической многомерной модели данных – "взрывной" рост ячеек многомерного пространства при увеличении числа измерений и количества координат в составе измерений. Объем многомерного пространства при этом возрастает по экспоненте. Количество ячеек, заполненных NULL-значениями, на порядки превышает количество ячеек, заполненных реальными данными. С целью сжатия многомерного пространства используется прием, реализованный в навигационной модели данных – адресные указатели, связывающие в том или ином порядке ячейки со значимыми данными. Сжатое многомерное пространство, в свою очередь, требует замены механизма поиска, основанного на однократных перемещениях вдоль осей измерений, на механизм поиска, основанный на иерархических структурах. В этом виде многомерная модель может быть отнесена к группе навигационных моделей данных. Так же как иерархическую и сетевую, многомерную модель целесообразно дополнить механизмом ссылок в виде внешних ключей, связывающих данные, расположенные в разных гиперкубах. Полученную модель данных можно определить как интегрированную модель, вобравшую лучшие качества иерархической (механизм поиска), сетевой (произвольный доступ) и реляционной (логическое разделение первичных структур хранения информации) моделей данных. Использование интегрированной модели позволит отказаться от двойного представления информации, реализованного в гибридных многомерно-реляционных базах данных, предлагаемых ведущими производителями данного класса программного обеспечения. Это дополнительно увеличит скорость доступа к данным. Интегрированная модель данных имеет широкие перспективы развития в направлении многоверсионной архитектуры, замены процедуры, опережающей записи в журнал транзакций, на специальные алгоритмы контроля полноты и достоверности контроля без обращения к энергонезависимому носителю информации, управления отдельными экземплярами атрибутов данных и т.д. В заключение необходимо подчеркнуть важность сохранения преемственности в использовании всего комплекса знаний и практического опыта, накопленных в области управления базами данных, в первую очередь достижений в контроле транзакций, поддержке версий данных, развитого языка программирования, совершенных механизмах репликации и масштабирования. Интегрированная модель, безусловно, должна быть оснащена всеми современными средствами управления базами данных.