Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 27)

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

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

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

Если подобную систему перенести без перепроектирования в ма­шинную форму, то это повлечет за собой необходимость создания по меньшей мере стольких файлов/таблиц с разной структурой, сколько имеется разных учебных планов. Число полей в каждом файле будет велико. Без знания учебного плана спроектировать структуру такой БД нельзя. Общее число файлов БД будет еще больше, поскольку для каждого семестра придется делать свой файл, так как в противном случае надо указывать где-то семестр, в котором студент сдавал экза­мен; особенно это важно, если по одному и тому же предмету сдается несколько экзаменов.

Каждый раз, когда в учебный план вводятся новые дисциплины, придется менять структуру БД. Обрабатывать БД с такой структурой чрезвычайно тяжело. Например, чтобы знать, какие оценки у студен­та X по физике, нужно знать, в какой группе учится данный студент, какая (какие) таблица содержит сведения об его успеваемости, сколь­ко оценок по физике он имеет и как называются соответствующие поля, в которых отражены эти оценки. Многие другие запросы также сформулировать будет сложно. Таким образом, это решение представ­ляется неудовлетворительным по всем основным показателям: пло­хие адаптивные свойства, велика сложность структуры и обработки. Универсальность системы равна нулю.

Если предложить другой вариант, а именно создать таблицу «Ус­певаемость» с полями «Код_студента», «Предмет», «Семестр», «Оцен­ка», то все указанные недостатки, отмеченные для первого проектно­го решения, будут устранены.

Недостатком же второго варианта по сравнению с первым будет большая степень дублирования данных: в первом варианте «ФИО/ Код_студента» фиксируется только один раз как значение поля, а на­звания предметов вообще фиксируются только в описании структу­ры, а во втором варианте они будут повторены как значения соответствующих полей при фиксации каждого факта сдачи экзамена. Но, несмотря на указные недостатки, предпочтение все равно должно быть отдано этому варианту.

Значимость критериев для каждого конкретного проекта будет зависеть от многих объективных и субъективных факторов. Прежде всего она зависит от самого критерия. Среди них есть такие, значи­мость которых не только никогда не понижается, а наоборот, постоянно растет (например, адекватное отображение действительности, удов­летворение разнообразных потребностей пользователей и т.п.). Ак­туальность других критериев становится менее существенной с рос­том возможностей техники и программного обеспечения (например, занимаемый базой данных объем памяти).

На значимость критерия оценки влияют особенности ИС, для кото­рой создается проект (например, для систем, работающих в реальном масштабе времени, очень важна скорость реакции системы на запросы, для банковских систем - защита информации и надежность системы).

3.2. Особенности даталогических моделей

3.2.1. Внутризаписная структура

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

В иерархической внутризаписной структуре в состав записи мо­гут входить не только простые, но и составные компоненты. Это мо­гут быть векторы (когда повторяются однотипные элементы), повто­ряющиеся группы (когда в записи может присутствовать несколько экземпляров составных единиц информации, включающих в себя несколько разнотипных элементов), а также неповторяющиеся состав­ные единицы информации внутри записи. Например, если имеется запись «Личность», то в ее состав могут входить простые элементы, такие, как «Табельный_номер», «Фамилия» и т.д., вектор «Иностранный_язык» (предполагается, что человек может владеть несколькими иностранными языками), повторяющаяся группа «Послужной_список», включающая элементы: «Дата_назначения», «Дата_увольнения»,

«Место_работы», «Должность», а также неповторяющаяся группа «Адрес», состоящая из элементов «Город», «Улица», «Дом», «Квартира».

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

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

Другой характеристикой записи является тип ее длины. По этому признаку различают записи с фиксированной (постоянной), перемен­ной и неопределенной длиной. Запись может иметь переменную дли­ну в результате того, что переменную длину имеют ее поля, или воз­можно отсутствие каких-либо полей, или допускается разное число экземпляров для повторяющихся компонентов.

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

3.2.2. Межзаписная структура

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

Иерархические модели. В классических иерархических моделях имеется один файл, который является входом в структуру (корень де­рева). Остальные файлы связаны друг с другом таким образом, что каждый из них, за исключением корневой вершины, имеет ровно одну исходную вершину («родитель») и любое число подчиненных вер­шин («детей»). Между записью файла-родителя и записями порож­денного файла имеется отношение 1:М (как частный случай может быть и отношение 1:1). Имеются и другие разновидности иерархи­ческих моделей, но они менее распространены.

Сетевые модели. Если на сетевые модели не накладывается ни­каких ограничений, в принципе любой файл может быть точкой вхо­да в БД, каждый из файлов может быть связан с произвольным чис­лом других файлов и между записями связанных файлов могут быть любые отношения (1:1, 1:М, М:М). Однако в реальных СУБД на мо­дель накладываются различные ограничения. Так, имеются сетевые СУБД с разнотипными файлами. В них все файлы разделены на два типа: основные и зависимые. В таких СУБД входом в базу данных Могут служить только основные файлы, а связываться между собой могут только разнотипные файлы.

Во многих сетевых СУБД не поддерживается непосредственно отношение М:М. В таких моделях каждая связь между парой файлов определяется отдельно, и для каждой из них один файл в этой паре объявляется владельцем, а другой - членом. Отношение между запи­сью-владельцем и записями-членами - 1:М.

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

Реляционные модели. В таких моделях используется своеобраз­ная терминология, но это не меняет сущности модели. Часто даже в рамках одной модели в разных СУБД используется разная термино­логия. Так, на логическом уровне элемент чаще всего называют атри­бутом; кроме того, для него используются термины «колонка», «столбец», «поле». Совокупность атрибутов образует строку (синонимич­ные термины - «ряд», «запись», «кортеж»). Совокупность строк об­разует отношение («таблицу», «файл базы данных»). Понятие базы данных как множества отношений поддерживается далеко не всеми реляционными СУБД (т.е. при создании БД описываются отдельные отношения (файлы, таблицы), а для всей базы данных как самостоя­тельной информационной единицы никакого описания не предусмот­рено). Однако следует отметить, что в последнее время новые версии даже тех настольных СУБД, которые раньше не поддерживали поня­тие БД, сейчас его включают.

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

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

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

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

В случае если СУБД поддерживает концепцию ключа, при нали­чии нескольких вероятных ключей один из них выбирается и описы­вается как первичный, остальные — как альтернативные (обычно для этих целей используется либо уникальный индекс, либо описатель UNIQUE при определении таблицы).

Атрибут (или группа атрибутов), который в рассматриваемом от­ношении не является ключом, а в другом отношении - является, на­зывается внешним ключом.

Если какая-либо таблица содержит внешний ключ, то она логи­чески связана с таблицей, содержащей соответствующий первичный ключ; эта связь имеет характер «один ко многим» (таблица, содержа­щая внешний ключ, находится на стороне «много» в этой связи). В част­ном случае это может быть связь 1:1. Связь М:М в реляционной базе данных непосредственно не поддерживается.

По сути, понятия «родитель» - «ребенок» в иерархических мо­делях, «файл-владелец» - «файл-член» в сетевых моделях и связь «ключ» - «внешний ключ» в реляционных моделях передают одно и то же явление — наличие связи 1 :М между записями соответствую­щих файлов.

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

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

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

3.3. Проектирование логической структуры реляционной базы данных

3.3.1. Вводные положения

Для реляционной базы данных проектирование логической струк­туры заключается в том, чтобы разбить всю информацию по файлам^ (или в терминах реляционной модели - по отношениям, таблицам), а также определить состав полей (в терминах реляционной теории -атрибутов) для каждого файла. Определение ключа каждого из отно­шений также является задачей логического проектирования реляци­онной БД.

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

Часто при описании логической структуры реляционной БД сразу же указывается, по каким полям надо индексировать соответствующий файл, а для ключевых полей автоматически предусматривается индек­сация. Индексация занимает промежуточное положение между логи­ческой и физической структурой данных: с одной стороны, она опре­деляет способ упорядочения данных и доступ к ним, а с другой - это способ «логического упорядочения», при котором создаются вспомо­гательные индексные файлы, что меняет общую структуру БД. Вопро­сы индексирования будут частично рассмотрены в данном разделе.

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

Характеристики

Список файлов книги