YourLib.net
Твоя библиотека
Главная arrow Базы данных. Проектирование и создание (С.М. Диго) arrow 3.3. Особенности даталогических моделей
3.3. Особенности даталогических моделей

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

   В базах данных со структурированными моделями следует различать внутризапис- ную и межзаписную структуру. Внутризаписная структура может быть либо линейной, либо иерархической. При линейной структуре запись состоит из простых элементов (часто называемых полями), которые следуют в записи одно за другим, т.е. структура записи является нормализованной.
   В случае иерархической внутризаписной структуры в состав записи могут входить не только простые, но и составные компоненты. Это могут быть векторы (когда повторяются однотипные элементы), повторяющиеся группы (когда в записи может присутствовать несколько экземпляров составных единиц информации, включающих в себя несколько разнотипных элементов), а также неповторяющиеся составные единицы информации внутри записи. Например, если мы имеем запись ЛИЧНОСТЬ, то в ее состав могут входить простые элементы, такие как ТАБЕЛЬНЫЙ_НОМЕР, ФАМИЛИЯ и т.д., вектор ИНОСТРАННЫЙ_ЯЗЫК (предполагается, что человек может владеть несколькими иностранными языками), повторяющаяся группа ПОСЛУЖНОЙ_СПИСОК, включающая элементы: ДАТА_НАЗНАЧЕНИЯ, ДАТА_УВОЛЬНЕНИЯ, МЕСТО_РАБОТЫ, ДОЛЖНОСТЬ, а также неповторяющаяся группа АДРЕС, состоящая из элементов ГОРОД, УЛИЦА, ДОМ, КВАРТИРА.
   Иерархическая структура записи может быть как одноуровневой, так и многоуровневой. Принципиально возможны довольно сложные структуры, например когда в состав повторяющейся группы в качестве составляющего компонента входит другая повторяющаяся группа. Однако по разным причинам (в частности, из-за сложности реализации) в конкретных СУБД имеются различные ограничения (например, повторяющаяся группа может существовать только на первом уровне иерархии, ограничивается число уровней иерархии и т.п.).
   Записи могут быть с постоянным и переменным составом. Последнее обычно понимается так: если значение какого-либо компонента записи отсутствует для конкретного объекта, то и сам этот компонент в данной записи отсутствует. Например, если один из сотрудников окончил вуз, имеет ученую степень и ученое звание, то название вуза, год его окончания, ученая степень, ученое звание и даты их присвоения хранятся в записи, соответствующей данному сотруднику. Если у другого сотрудника все эти признаки отсутствуют, то в соответствующей ему записи эти поля также отсутствуют. В случае если записи имеют постоянный состав, то все поля, описанные в структуре записи, всегда присутствуют в каждом экземпляре записи, но некоторые из этих полей могут быть «пустыми».
   Другой характеристикой записи является тип ее длины. По этому признаку различают записи с фиксированной (постоянной), переменной и неопределенной длиной. Запись может иметь переменную длину в результате того, что переменную длину имеют ее поля, либо возможно отсутствие каких-либо полей, либо допускается разное число экземпляров для повторяющихся компонентов.
   Поле является наименьшим семантически значимым элементом записи. Основными характеристиками поля является его тип и длина. Существующие СУБД различаются по набору поддерживаемых типов полей, но наблюдается тенденция к расширению этого набора. Большинство современных СУБД, кроме привычных полей символьного и числового типа, допускают использование полей типа даты, логических полей, а также полей денежного типа. Некоторые системы позволяют вводить определяемые пользователем типы полей. В последнее время все большее распространение получают мультимедийные формы представления данных.
   Традиционное деление СУБД по типу модели данных на реляционные, иерархические и сетевые основывается на характере связей между записями. При всей разнице в терминологии можно считать, что основными компонентами любой из этих моделей являются файлы, которые состоят из записей.
   В классических иерархических моделях имеется один файл, который является входом в структуру (корень дерева). Остальные файлы связаны друг с другом таким образом, что каждый из них, за исключением корневой вершины, имеет ровно одну исходную вершину («родитель») и любое число подчиненных вершин («детей»). Между записью файла-«родителя» и записями порожденного файла имеется отношение 1:М (как частный случай может быть и отношение 1:1).
   Имеются и другие разновидности иерархических моделей, но они менее распространены.
   В сетевых моделях, если на них не накладывается никаких ограничений, в принципе, любой файл может быть точкой входа в БД, каждый из файлов может быть связан с произвольным числом других файлов и между записями связанных файлов могут быть любые отношения (1:1, 1:М, М:М). Однако в реальных СУБД на модель накладываются различные ограничения. Так, имеются сетевые СУБД с разнотипными файлами. В них все файлы разделены на два типа: основные и зависимые. В таких СУБД входом в базу данных могут служить только основные файлы, а связываться между собой могут только разнотипные файлы.
   Во многих сетевых СУБД не поддерживается непосредственно отношение М:М. В таких моделях каждая связь между парой файлов определяется отдельно, и для каждой из них один файл в этой паре объявляется «владельцем», а другой - «членом». Отношение между записью-«владельцем» и записями-«членами» - 1:М.
   Связи между файлами в иерархических и сетевых моделях определяются при описании структуры базы данных и физически чаще всего передаются при помощи различных указателей.
   В реляционной модели используется своеобразная терминология, но это не меняет сущности модели. Часто даже в рамках одной модели в разных СУБД используется разная терминология. Так, на логическом уровне элемент чаще всего называют атрибутом; кроме того, для него используются термины «колонка», «столбец», «поле». Совокупность атрибутов образует строку (синонимичные термины - «ряд», «запись», «кортеж»). Совокупность строк образует отношение («таблицу», «файл базы данных»). Понятие базы данных как множества отношений поддерживается далеко не всеми реляционными СУБД (т.е. при создании БД описываются отдельные отношения (файлы, таблицы), а для всей базы данных, как самостоятельной информационной единицы, никакого описания не предусмотрено). Хотя следует отметить, что в последнее время новые версии даже тех «настольных» СУБД, которые раньше не поддерживали понятие БД, сейчас его включают.
   Связи между файлами в реляционной модели в явном виде могут не описываться. Они устанавливаются динамически в момент обработки данных по равенству значений соответствующих полей.
   В сетевых и иерархических моделях структура записи, в принципе, может быть любой. Хотя многие СУБД накладывают различные ограничения на структуру записи. В реляционных моделях структура записи должна быть линейной.
   Каждое отношение по определению имеет ключ, т.е. атрибут (простой ключ) или совокупность атрибутов (составной ключ), однозначно идентифицирующих кортеж. В некоторых случаях в отношении могут быть несколько возможных (вероятных, альтернативных) ключей.
   К сожалению, не все реляционные СУБД поддерживают концепцию ключа, так как в этом случае многие проблемы (в частности, обеспечение проверки на уникальность ключа и соблюдение некоторых других ограничений целостности) возлагаются на пользователя (проектировщика ИС). Вне зависимости от того, требует СУБД явного указания ключей при описании отношений или нет, проектировщик базы данных должен понимать, что является ключом каждого отношения.
   В случае если СУБД поддерживает концепцию ключа, при наличии нескольких вероятных ключей один из них выбирается и описывается как первичный ключ, остальные - как альтернативные (обычно для этих целей используется либо уникальный индекс, либо описатель UNIQUE при определении таблицы). Атрибут или группа атрибутов, которая в рассматриваемом отношении не является ключом, а в другом отношении ключом является, называется внешним ключом.
   Если таблица содержит внешний ключ, то она: а) логически связана с таблицей, содержащей соответствующий первичный ключ; б) эта связь имеет характер «один-ко- многим» (таблица, содержащая внешний ключ, находится на стороне «много» в этой связи). В частном случае это может быть связь 1:1. Связь М:М в реляционной базе данных непосредственно не поддерживается.
   По сути, понятия «родитель» - «ребенок» в иерархических моделях, файл- «владелец» - файл-«член» в сетевых моделях и связь «ключ» - «внешний ключ» в реляционных моделях передают одно и то же явление - наличие связи 1:М между записями соответствующих файлов.
   В реляционных СУБД часто используется понятие «взгляд» (view). Он представляет собой виртуальную таблицу, часто полученную в результате логического соединения нескольких связанных по значениям общих столбцов таблиц и, возможно, включающую некоторое подмножество из всей совокупности строк, отобранное по заданному условию. Это понятие расширяет традиционное для банков данных понятие «подсхема». Понимание различий и общности моделей разных классов позволяет использовать общий подход при проектировании структуры баз данных, осуществлять преобразование одних моделей в другие, использовать средства, в частности языковые, предназначенные для работы с одним классом моделей, при работе с другим.
   Существует еще одна разновидность моделей данных - системы, построенные на основе инвертированных файлов. С точки зрения логической структуры БД эти модели следует отнести к сетевым. Более того, это единственный вид моделей, которые в явном виде поддерживают отношение M:M между файлами БД. Особенности этих моделей заключены в способе отражения связей между информационными единицами. В системах, построенных на основе инвертированных файлов, собственно хранимые данные и информация о связях между информационными единицами логически и физически отделены друг от друга. Основные данные в этих системах хранятся в файлах, записи которых могут иметь многоуровневую иерархическую структуру. Вся управляющая информация сосредоточена в так называемом ассоциаторе. Логическая связь между файлами устанавливается посредством компонента ассоциатора, называемого сетью связи. Отделение ассоциативной информации от собственно хранимых данных позволяет изменять связи, не изменяя при этом самих файлов.

 
< Пред.   След. >