Лекция 4

Логическое проектирование (? даталогическое)

Выбор СУБД

Основная цель при подборе СУБД – выбор системы, удовлетворяющей текущим и прогнозируемым требованиям организации при оптимальном уровне затрат. Затраты могут включать расходы на приобретение СУБД и дополнительного аппаратного и программного обеспечения, а также расходы, связанные с переходом к новой системе и необходимостью переобучения персонала.

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

Если раньше выбор инструментальных средств (в том числе СУБД) производился исходя из предпочтений разработчика вне зависимости от специфики предметной области и перспектив использования базы данных, то на современном этапе развития программного обеспечения, когда на рынке предлагается необозримое количество СУБД, выбор средства реализации БД становится сложной задачей. Принятие строго оптимального решения в таких условиях желательно, но затруднено.

В общем виде процесс выбора СУБД включает следующие этапы:

1. определение списка показателей; по которым будут оцениваться СУБД;

2. определение списка сравниваемых СУБД;

3. оценка продуктов по выбранным показателям;

4. принятие обоснованного решения, подготовка отчета.

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

Даталогические модели данных

Модель данных – фиксированная система понятий и правил для представления структуры данных, состояния и динамики проблемной области в базах данных. Как правило, задается языком определения данных и языком манипулирования данными. Примерами модели данных, получившими широкое распространение, являются модели данных сетевая, иерархическая, реляционная и др.

Модель данных состоит из трех компонент [11].

1. Структура данных.

2. Допустимые операции, выполняемые на структуре данных.

3. Ограничения для контроля целостности.

Схема – это средство, с помощью которого определяется модель данных приложения.

Иерархическая модель

Схема БД, в которой каждый из представленных в ней типов записи (кроме одного, корневого, типа записи) связан с несколькими (в том числе, и ни с одним) различными типами записи, расположенными ниже его по иерархии, и в точности с одним типом записи, находящимся выше рассматриваемого типа по иерархии, называется иерархи­ческой схемой, а соответствующая СУБД – иерархической СУБД. Корневой тип записи находится на высшем уровне в этой иерархии и не имеет записи-владельца.

Объекты, связанные иерархическими отношениями, образуют ориентированный граф (перевернутое дерево), вид которого представлен на рис. 22. Пример схемы иерархической модели БД представлен на рис. 23.

Рис. 22. Графическое изображение иерархической структуры БД

Рис. 23. Схема иерархической модели БД

Иерархическая модель БД на рис. 23 состоит из 10 разных типов запи­си: Учебная дисциплина, Аудитория, Преподаватель, Рабочая программа, Квалификация, Учебный план, Лекция, Курсовая работа, Лабораторная работа, Практическое занятие и четырех типов набора: Элементы учебной дисциплины, Квалификация преподавателя, Элементы программы, Элементы плана. Все связи между типами записи в этом примере соответ­ствуют отношениям «один ко многим», или, как частный случай, «один к одному».

Рис. 23. Иерархическая древовидная структура модели БД

Основные достоинства иерархической модели – простота опи­сания иерархических структур реального мира и быстрое выпол­нение запросов. Однако не всегда удобно каждый раз начинать поиск нужных данных с корня, а другого способа перемещения по базе в иерархических структурах нет.

Сетевая модель

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

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

На рис. 24 изображена сетевая структура базы данных в виде графа.

Рис. 24. Графическое изображение сетевой структуры БД

Примером сложной сетевой структуры может служить структура БД, содержащей сведения о студентах, участвующих в научно-исследовательских работах (НИРС). Возможно участие одного студента в нескольких НИРС, а также участие нескольких студентов в разработке одной НИРС. Графическое изображение описанной в примере сетевой структуры, состоящей только из двух типов записей, показано на рис. 25. Единственное отношение представляет собой связь между записями в обоих направлениях.

Рис. 25. Пример сетевой структуры БД

В примере, приведенном на рис. 25, каждый преподаватель мо­жет обучать многих (теоретически всех) студентов и каждый студент может обучаться у многих (теоретически у всех) преподава­телей.

Рис. 25. Сетевая структура модели БД

Использование иерархической и сетевой моделей ускоряет до­ступ к информации в базе данных. Однако, поскольку каждый элемент данных должен содержать ссылки на некоторые другие элементы, требуются значительные ресурсы как дисковой, так и основной памяти ЭВМ. Недостаточность основной памяти, ко­нечно, снижает скорость обработки данных. Кроме того, для та­ких моделей характерна сложность реализации системы управле­ния базами данных.

Реляционная модель

Реляционная модель (от англ. relation – отношение) была раз­работана в начале 70-х годов XX в. Коддом. Простота и гибкость этой модели привлекли к ней внимание разработчиков, и уже 80-х годах XX в. она получила широкое распространение. Таким образом, реляционные СУБД оказались промышленным стандар­том.

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

В реляционной модели информация представляется в виде пря­моугольных таблиц, каждая из которых состоит из строк и столб­цов и имеет имя, уникальное внутри базы данных.

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

В отличие от столбцов строки не имеют имен, порядок их сле­дования в таблице не определен, а число – логически не ограни­чено. Так как строки в таблице не упорядочены, невозможно выб­рать строку по ее позиции. Номер, имеющийся в файле у каждой строки, не характеризует ее, так как его значение изменяется при удалении строк из таблицы. Логически не существует первой и последней строк.

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

В каждой таблице реляционной модели должен быть столбец (или совокупность столбцов), значение которого однозначно иден­тифицирует каждую ее строку. Этот столбец (или совокупность столбцов) и называется первичным ключом таблицы (рис. 26).

Таблица 1. Сотрудник

Н омер пропуска	ФИО	Должность	Н азвание отдела	Телефон

Первичный ключ табл. 1

Внешний ключ табл. 1

Таблица 2. Отдел

Н азвание отдела	Расположение отдела	Назначение отдела

Первичный ключ табл. 2

Рис. 26. Организация ссылки от одной таблицы к другой

Если таблица удовлетворяет требованию уникальности пер­вичного ключа, она называется отношением. В реляционной мо­дели все таблицы должны быть преобразованы в отношения. От­ношения реляционной модели связаны между собой. Связи под­держиваются внешними ключами. Внешний ключ – это столбец (совокупность столбцов), значение которого однозначно харак­теризует значения первичного ключа другого отношения (табли­цы).

Говорят, что отношение, в котором определен внешний ключ, ссылается на соответствующее отношение, в котором та же сово­купность столбцов является первичным ключом.

В приведенном на рис. 26 примере отношение СОТРУДНИК ссылается на отношение ОТДЕЛ через название отдела.

Доминирование реляционной модели в современных СУБД определяется:

1. наличием развитой теории (реляционной алгебры);

2. наличием аппарата сведения других моделей данных к реляци­онной модели;

3. наличием специальных средств ускоренного доступа к инфор­мации;

4. наличием стандартизированного высокоуровневого языка зап­росов к БД, позволяющего манипулировать ими без знания кон­кретной физической организации БД во внешней памяти.

Будучи математиком по образованию Э.Кодд предложил использовать для обработки данных аппарат теории множеств (объединение, пересечение, разность, декартово произведение). Он показал, что любое представление данных сводится к совокупности двумерных таблиц особого вида, известного в математике как отношение – relation (англ.).

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

Доменом называется множество атомарных значений одного и того же типа. Так, на рис. 27 домен пунктов отправления (назначения) – множество названий населенных пунктов, а домен номеров рейса – множество целых положительных чисел.

Рис. 27. Отношение в реляционной модели

Заголовок состоит из такого фиксированного множества атрибутов А₁, А₂, ..., А_п, что существует взаимно однозначное соответствие между этими атрибутами А_i и определяющими их доменами D_i = (i=1, 2, ..., n).

Тело состоит из меняющегося во времени множества кортежей, где каждый кортеж состоит в свою очередь из множества пар атрибут-значение (А_i:V_i), (i=1, 2, ..., n), по одной такой паре для каждого атрибута А_i в заголовке. Для любой заданной пары атрибут-значение (А_i:V_i) V_i является значением из единственного домена D_i, который связан с атрибутом А_i.

Степень отношения – это число его атрибутов. Отношение степени один называют унарным, степени два - бинарным, степени три – тернарным, ..., а степени n – n-арным,

Кардинальное число или мощность отношения – это число его кортежей. Кардинальное число отношения изменяется во времени в отличие от его степени.

_____________________

Реляционная БД представляет собой инфор­мацию (данные) об объектах, представленную в виде двумерных массивов – таблиц, объединенных определенными связями. База данных может состоять и из одной таблицы.

Рассмот­рим применяемые в теории и практике термины и определения.

Таблица базы данных – двумерный массив, содержащий ин­формацию об одном классе объектов. В теории реляционной ал­гебры двумерный массив (таблицу) называют отношением.

Таблица состоит из следующих элементов: поле, ячейка, за­пись (рис. 28).

Поле содержит значения одного из признаков, характеризу­ющих объекты БД. Число полей в таблице соответствует числу при­знаков, характеризующих объекты БД.

Ячейка содержит конкретное значение соответствующего поля (признака одного объекта).

Запись – строка таблицы. Она содержит значения всех призна­ков, характеризующих один объект. Число записей (строк) соот­ветствует числу объектов, данные о которых содержатся в таб­лице.

В теории баз данных термину запись соответствует понятие кор­теж – последовательность атрибутов, связанных между собой от­ношением AND (И). В теории графов кортеж означает простую ветвь ориентированного графа – дерева.

В табл. 1 приведены термины, применяемые в теории и прак­тике разработки реляционных баз данных.

Теория БД	Реляционные СУБД (FoxPro, Microsoft Access)	SQL Server 7.0
Отношение (Relation)	Таблица (Table)	Таблица (Table)
Атрибут (Attribute)	Поле (Field)	Колонка (Column)
Кортеж (Tuple)	Запись (Record)	Строка (Row)

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

Ключом считается поле, значения которого однозначно опреде­ляют значения всех остальных полей в таблице. Например, поле «Номер паспорта», или «Идентификационный номер налогопла­тельщика (ИНН)», однозначно определяет характеристики любого физического лица (при составлении соответствующих таблиц баз данных для отделов кадров или бухгалтерии предприятия).

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

Уникальность ключа означает, что в любой момент времени таблица базы данных не может содержать никакие две различные записи, имеющие одинаковые значения ключевых полей. Выпол­нение условия уникальности является обязательным.

Условие минимальности ключевых полей означает, что только сочетание значений выбранных полей отвечает требованиям уни­кальности записей таблицы базы данных. Это означает также, что ни одно из входящих в ключ полей не может быть исключено из него без нарушения уникальности.

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

• не следует включать в состав ключа поля таблицы, значения которых сами по себе однозначно идентифицируют записи в таб­лице. Например, не стоит создавать ключ, содержащий одновре­менно поля «номер паспорта» и «идентификационный номер на­логоплательщика», поскольку каждый из этих атрибутов может однозначно идентифицировать записи в таблице;

• нельзя включать в состав ключа неуникальное поле, т.е. поле, значения которого могут повторяться в таблице.

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