|
|
|
сделать стартовой | добавить в избранное |
 |
|
Компьютеры, Программирование Программное обеспечение
Иерархические структуры данных в реляционных БД |
Карабин, 6x60 мм. 
Ночник-проектор "Звездное небо и планеты", фиолетовый. 
Крючки с поводками Mikado SSH Fudo "SB Chinu", №4BN, поводок 0,22 мм. Михаил Голованов Введение Архитектура реляционных баз данных ориентирована на хранение внутри таблиц БД информации о сущностях информационной системы и связях между ними. Каждая из записей таблицы содержит информацию об одном экземпляре. Организация хранения информации о независимых друг от друга экземплярах сущностей (т.е. так называемых «плоских» данных) не вызывает никаких затруднений. Однако, наряду с «плоскими» данными, при построении даже простых информационных систем, приходится хранить в БД и информацию о «вложенных» друг в друга сущностях, т.е иерархические данные. Организация хранения такой информации в реляционных БД проста, но не всегда очевидна для тех, кто впервые сталкивается с подобной задачей. В данной статье я попытаюсь поделиться накопленным опытом. Примеры, приводимые далее, были созданы и протестированы с помощью I erbase 6. Иерархии данных Чтобы обсудить проблему хранения иерархии в реляционной БД, мы вначале рассмотрим вопрос о том, какие же иерархии данных могут встретиться на практике. В реальной жизни иерархии имеют, как правило, некоторые ограничения. Учитывая эти ограничения, можно построить более эффективные процедуры обработки иерархических данных. Так, в общем случае, дерево может иметь любое количество уровней иерархии. Но в частных случаях число уровней может, и часто оказывается, конечным. Может быть ограничено количество непосредственных потомков одного элемента иерархии. Рассмотрим некоторые варианты представления иерархических структур в реляционных БД. Возможные варианты структур БД для хранения иерархий Наиболее общим случаем является дерево с неограниченным уровнем вложенности и неограниченным количеством потомков. Для хранения такого рода иерархии необходимо добавить в описание сущности дополнительное поле – ссылку на первичный ключ предка. Такой способ организации иерархии является самым распространенным и универсальным. Однако ему присущи следующие недостатки: Необходимость рекурсивных запросов для получения полного пути от произвольного элемента до корня дерева. Сложность вычисления уровня вложенности произвольного элемента. Сложность получения всех (в том числе и не прямых) потомков данного узла. Дальнейшее рассмотрение мы будем вести на примере построения иерархической структуры – тематического каталога библиотеки. Данный каталог применяется для классификации, сортировки и поиска книг по их содержанию. Будем считать, что каждый элемент каталога описывается собственным неуникальным символьным именем. Для обеспечения уникальности записей для каждого элемента каталога необходимо ввести первичный ключ. Для поддержки иерархичности данных введем дополнительное поле-ссылку на предка данного элемента иерархии. Ниже приведено описание полученной структуры на языке SQL: CREA E ABLE "CA ALOG" ( "ID" I EGER O ULL PRIMARY KEY, " AME" VARCHAR(200) CHARAC ER SE WI 1251 O ULL, "PARE ID" I EGER ); Данная структура является минимально необходимой и достаточной для организации и хранения иерархии. Назовем ее структурой со ссылкой на предка. В данной структуре присутствует как минимум один недостаток – отсутствие контроля правильности ссылки на родителя.
Какие же значения поля PARE ID являются правильными? Ответ очевиден – весь диапазон значений первичного ключа (поля ID) одно значение, используемое для обозначения отсутствия родительского элемента. Данное значение необходимо для ввода и хранения корневых элементов иерархии. Чаще всего в качестве значения, обозначающего отсутствие родителя, используется ULL, хотя нет никаких физических ограничений для использования других значений. Так, например, если вы уверены, что значения первичного ключа будут больше 0, в качестве признака корневого элемента можно использовать значение (–1) или другие отрицательные значения в поле PARE ID. Я не буду оригинален и в качестве значения PARE ID для корневых элементов использую ULL. Тогда для контроля правильности PARE ID можно использовать следующее ограничение: "PARE ID" I EGER CHECK( ("PARE ID" IS ULL) OR ( "PARE ID" = A Y(SELEC "ID" FROM "CA ALOG") ) ) (в принципе, такие ограничения намного проще и эффективнее описывать как внешние ключи. Единственной проблемой при этом является вставка корневой записи, т.к. родительской записи для нее не существует. Обойти такое ограничение можно, добавляя внешний ключ после вставки корневой записи. – прим.ред.) Вернемся к отмеченным выше недостаткам данной структуры (сложность формирования полного пути и вычисления уровня элемента). Эти недостатки вытекают из того простого факта, что в данной структуре информация о полном пути и уровне нигде не хранится. Решить проблему быстрого получения уровня вложенности можно введением в структуру таблицы дополнительного поля Level. Описание таблицы тогда будет выглядеть так: CREA E ABLE "CA ALOG" ( "ID" I EGER O ULL PRIMARY KEY, " AME" VARCHAR(200) CHARAC ER SE WI 1251 O ULL, "PARE ID" I EGER CHECK( "PARE ID" = A Y(SELEC "ID" FROM "CA ALOG") or "PARE ID" is ULL ), "LEVEL" I EGER DEFAUL 1 O ULL ); Структура для хранения иерархии с неограниченным числом уровней вложенности и потомков готова. Следующей по степени универсальности является иерархия с неограниченным числом уровней вложенности и конечным числом потомков элемента иерархии. Ограничение количества потомков позволяет хранить данные в следующем виде. Ссылка на предка Информация о первом элементе уровня иерархии Информация о втором элементе уровня иерархии Информация о -ном элементе уровня иерархии, где – количество максимальное количество потомков Ссылка на предка содержит в себе ссылку на запись, хранящую информацию о предыдущем уровне иерархии и смещение (номер столбца) с описанием родителя. В нашем примере мы ограничим количество предков числом 5, тогда SQL-описание таблицы будет выглядеть следующим образом: CREA E ABLE "CA ALOG2" ( "LEVEL" I EGER O ULL, "OFFSE " SMALLI O ULL CHECK("OFFSE " > 0 a d "OFFSE " &l ; 6), " AME 1" VARCHAR(200) CHARAC ER SE WI 1251, " AME 2" VARCHAR(200) CHARAC ER SE WI 1251, " AME 3" VARCHAR(200) CHARAC ER SE WI 1251, " AME 4" VARCHAR(200) CHARAC ER SE WI 1251, " AME 5" VARCHAR(200) CHARAC ER SE WI 1251, "PARE LEVEL" I EGER, "PARE OFFSE " SMALLI CHECK(("PARE OFFSE " > 0 a d "PARE OFFSE " &l ; 6) or ("PARE OFFSE " is ULL)), CO S RAI "PK CA ALOG2" PRIMARY KEY("LEVEL","OFFSE ") ); Больших преимуществ использования такой структуры я не вижу, недостаток же налицо – при изменении максимального количества потомков одного узла придется добавлять еще один столбец таблицы, что крайне неудобно.
По этой причине подробно рассматривать эту структуру мы не станем, а перейдем к следующему случаю – иерархии с конечным числом уровней вложенности и бесконечным числом потомков узла. Одним из вариантов хранения таких иерархий является поуровневое хранение в различных таблицах. Например, таблица CA ALOG LEVEL 1 хранит все элементы первого уровня вложенности, таблица CA ALOG LEVEL 2 – второго, и т.д. Ниже приведено описание такой структуры для случая трехуровневой иерархии. CREA E ABLE "CA ALOG3 LEVEL1" ( "ID" I EGER O ULL PRIMARY KEY, " AME" VARCHAR(200) CHARAC ER SE WI 1251 O ULL ); CREA E ABLE "CA ALOG3 LEVEL2" ( "ID" I EGER O ULL U IQUE, " AME" VARCHAR(200) CHARAC ER SE WI 1251 O ULL, "PARE ID" I EGER O ULL REFERE CES "CA ALOG3 LEVEL1"("ID"), PRIMARY KEY("ID","PARE ID") ); CREA E ABLE "CA ALOG3 LEVEL3" ( "ID" I EGER O ULL U IQUE, " AME" VARCHAR(200) CHARAC ER SE WI 1251 O ULL, "PARE ID" I EGER O ULL REFERE CES "CA ALOG3 LEVEL1"("ID"), "PARE ID2" I EGER O ULL REFERE CES "CA ALOG3 LEVEL2"("ID"), PRIMARY KEY ("ID", "PARE ID", "PARE ID2") ); При большем количестве уровней необходимо определить дополнительные таблицы для каждого уровня, по структуре аналогичные таблице CA ALOG3 LEVEL2. В данной структуре получение уровня элемента не представляет никакой сложности, т.к однозначно определяется таблицей, в которой он хранится. Полный путь от любого элемента до корня также определяется составным первичным ключом таблицы. Этот вид структуры назовем структурой с потабличным хранением уровней Последний из видов иерархии – иерархия с ограниченной вложенностью и ограниченным числом потомков. Многие из реальных задач, встречавшихся мне, в той или иной степени можно было свести к этому виду иерархии. Так, например, наша задача с каталогом библиотеки, хотя в строгом виде и является иерархией с неограниченным числом потомков узла и вложенностью, может быть сведена к рассматриваемому типу иерархии. Вполне можно ограничить количество элементов на одном уровне значением 9 (или другим достаточно большим числом) и 5 уровнями вложенности. Зачем? Затем, что в данном типе иерархии при определенной организации первичного ключа можно существенно упростить работу с иерархией. Для хранения данного вида иерархии можно использовать ранее описанные структуры иерархий с неограниченной вложенностью и количеством потомков и иерархий с ограниченным количеством уровней и неограниченным числом потомков. Однако есть две модификации структур специфичных для данного типа иерархии. Первый тип приведен ниже: CREA E ABLE "CA ALOG4" ( "ID" DECIMAL(5) O ULL PRIMARY KEY, " AME" VARCHAR(200) CHARAC ER SE WI 1251 O ULL ); Весь фокус в принципе формирования первичного ключа ID. Позиция последнего ненулевого десятичного разряда ключа – это уровень элемента, а цифра в этой позиции – номер элемента на данном уровне. Например, первый элемент первого уровня будет иметь ID = 00001, второй – 00002. На втором уровне третий элемент, имеющий предком первый элемент первого уровня, будет иметь ID = 00031, и т.д. Данная структура хороша при равномерном распределении элементов по уровням.
В зависимости от сильного государства оказываются его соседи, находящиеся на разном уровне развития, но в любом случае выплачивающие в знак признания своей зависимости определенную дань. Расширение земель и поток дани создает новые условия и возможности для правящих верхов. Успешно расширяющий свои владения правитель нередко дает своим родственникам практически теперь уже от своего имени участки земли, подчас целые области в своего рода кормления. И хотя доход с этой вотчины не принадлежит вновь назначенному владельцу, во всяком случае целиком, часть его становится объектом присвоения со стороны нового владельца. Более того, в условиях ослабления расширившегося государства этот владелец как, впрочем, и функционально близкий ему региональный администратор обычно превращается в автономного властителя и узурпирует право от собственного имени наделять родственников и приближенных более мелкими уделами и кормлениями, что способствует возникновению многоступенчатой иерархической структуры вас сально-феодального типа, столь хорошо известной и древности, и средневековью (речь идет о социально-политической структуре, а не о формации!)
3. Динамические структуры данных: очереди
4. Ведение реляционной БД на яз. CLIPPER 5.02
5. Динамические структуры данных: стеки
9. Разработка обучающей программы, поддерживающей изучение темы "Структуры данных"
10. Структури даних для обробки інформації
11. Фізична структура даних. Бухгалтерські інформаційні системи
12. Динамические структуры данных
13. Динамические структуры данных: дек
14. Реляционные Базы Данных. SQL - стандартный язык реляционных баз данных
15. Fox Pro - реляционная модель данных
16. Структура отитов у детей по данным ЛОР-отделения ПЦ НЦМ-РБ
Корзина "Плетенка" с крышкой, 35х29х17,5 см (коричневая). 
Увлекательная настольная игра "Цветариум", новая версия. 
Сковорода "Mayer & Boch" (гранитное покрытие), 24 см. 17. Структура и формирование исходных данных, необходимых для расчета параметров технологических схем
18. Введение в проектирование реляционных баз данных
20. Реляционные модели базы данных
21. Методика создания структуры базы данных на персональном компьютере
25. Файловые менеджеры как средство работы с иерархической файловой структурой
26. Типы и элементы планировочной структуры города
27. Концепции иерархической Вселенной по Лапласу
28. Эволюция, образование и структура Вселенной
29. Анализ медико-биологических данных с использованием Excel и СПП STADIA
30. Структура и состояние водоснабжения и водосброса, подземных вод и артезианских скважин города Киева
31. Подготовка данных и движение по азимутам
32. Статистика населения. Методы анализа динамики и численности и структуры населения
Этикетка самоклеящаяся "Lomond", А4, белая. 
Брелок "FIFA 2018. Забивака с двумя подвесками №2". 
Чудо трусики для плавания, от 0 до 3-х лет, трехслойные, арт. 1433, для девочек. 33. Структура транспорта в Европе
34. Экономическая система Дании
35. Минеральный состав, текстуры и структуры руд.
36. Аппарат государственной власти и его структура
37. Движение Сопротивления в Дании и Норвегии
42. Понятие и структура компетенции местного самоуправления
44. Налоги, их состав и структура
46. Понятие, структура и методики построения страховых тарифов
48. Структура и функции государственного аппарата
Велосипед трехколесный Moby Kids "Leader 360°. AIR Car", с разворотным сиденьем, цвет:. 
Батут. 
Копилка декоративная "Дружок", 12,5x10x12 см. 49. Сравнительное описание слоговых структур английского и каракалпакского языков
50. Культура, её структура и функции
51. Структура и организация учебного процесса в средневековом университете (Болонья, Париж, Прага)
52. Судьба и творчество Даниила Хармса
53. Проблематика и структура пьесы Б. Шоу "Пигмалион"
57. Методы компьютерной обработки статистических данных
58. Основные компоненты систем управления документооборотом. Фрейм: его структура и понятие
59. Интернет: административное устройство и структура глобальной сети
60. Построение сети передачи данных
61. Управление потоками данных в параллельных алгоритмах вычислительной линейной алгебры
62. Оценка методов и средств обеспечения безошибочности передачи данных в сетях
63. Системы и сети передачи данных
Набор цветных карандашей Trio, 18 цветов, утолщенные. 
Мольберт "Ника растущий", со счетами (синий). 66. Организация и применение микропроцессорных систем обработки данных и управления
67. Сжатие данных
68. Создание клиентских частей SQL БД под ОС Windows`95 и WindowsNT
69. Пример базы данных на Delphi 2.0
73. База данных для учета оплаты за междугородние разговоры
74. Построение информационной и даталогической моделей данных
75. Разработка базы данных `ДЕКАНАТ` в среде программирования "Delphi"
76. База данных "Домашняя библиотека"
77. Современные системы управления базами данных
78. Анализ пакетов обработки экспериментальных данных SABR и BOOTSTRAP
79. Разработка базы данных, отражающей учет успеваемости студентов
80. Разработка базы данных "Кадры"
Качели Фея "Чарли 3 в 1". 
Вожжи - страховка для ребенка Спортбэби "Комфорт". 
Ножницы "Pigeon" для ногтей новорожденных. 81. Разработка базы данных "Культурный досуг"
83. Семантический анализ структуры EXE файла и дисассемблер (с примерами и исходниками), вирусология
84. Алгоритм создания базы данных складского учета
85. Разработка базы данных для объекта автоматизации: гомеопатическая аптека
91. Системы принятия решений, оптимизация в Excel и базы данных Access
93. Ввод и редактирование данных в Word
94. КОНСОЛИДАЦИЯ ДАННЫХ И ФИЛЬТРЫ В MicroSoft Excel
95. База данных периодического издания
Звуковой плакат "Учимся читать - читаем по слогам". 
Сиденье для ванны (светло-голубое). 
Набор детской складной мебели Ника "Маленькая принцесса". 97. Управление структурой преподавательского состава в университете
98. Структура исчисления предикатов построение логического вывода
Шкатулка РТО, 35.5х25.5х20 см (арт. 3678-RT-60). 
