Ну, Дмитрий Юрьевич - известный провокатор. Однако в это раз он задал серьезный вопрос.

>>1. Пожалуйста, расскажите об основных способах классификации. Проиллюстрируйте Ваш рассказ структурами данных для их реализации.
Не совсем понятен вопрос. Что нужно классифицировать? С точки зрения содержания базы, то классификация ее сущностей должна соответсвовать реальному состоянию вещей.
Пример. В базе библитотеки должен быть, как минимум, код ISBN и также номер стелажа и номер полки.
Но сущности в базе сами по себе не могут быть классифицированы. Их классификация возможна только по их атрибутам.
Атрибуты могут быть условно-постоянными, например, название книги в библиотеке, рассчитываемыми - количество выдач данной книги, постоянными, например, количество рабочих дней библиотеки в феврале 2005 года.

>>2. Пожалуйста, приведите схемы реализации мультиязычности для реляционных баз данных. Пожалуйста, опишите недостатки схемы,
>>>рекомендованной SQL-2003.
Нафиг. Это тривиальная работа, подмена английских сообщений на русские. Да, кстати. Не читал "рекомендованной SQL-2003". На мой взгляд нужно перехватывать ошибки и давать юзеру нормальную информацию. Так, например, при попытки удаления записи, которая имеет подчиненные записи другой таблицы, вместо сообщения, не помню сейчас по памяти как оно точно звучит, но вроде "Ошибка удаления в таблице HUAREK по причине невозможности", нужно выдавать юзеру примерно такое сообщение "Невозможно удалить запись, так как есть зависимые от нее записи"

>>3. Пожалуйста, перечислите варианты реализации ограничения доступа к содержимому реляционных баз данных. Пожалуйста, приведите
>>структуры данных для их реализации.
Это для студентов вопрос. Мне даже писать это в лом.

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

>>5. Пожалуйста, расскажите о возможных способах хранения данных не реляционной природы в реляционных базах данных.
>>Пожалуйста, расскажите о моделях, метамоделях, наиболее распространенных стандартах и способах их описания в реляционных базах данных.
>>Проиллюстрируйте Ваш рассказ структурами данных.
В реляционных структурах могут храниться только реляционные данные. Главная трудность в создании реляционной базы данных - отражение в ней реальной структуры, которая, как правило, имеет иерархическую стуктуру. Приходится выбирать разумный компромис.

Юрий Дмитриевич, наверняка Вы знаете, что реляционные базы данных просто некая упрощенная модель реального состояния некоей системы, которая, модель, позволяет представить некие существуюшие в данной системе объекты в удобном для вычисления агрегатных функций виде? Нет проблем отобразить иерархическую структуру. Проблемы в иерархических базах начинаются тогда, когда нужно просуммировать атрибут N по ризнаку P.

>>6. На десерт. Обобщите ответы на предыдущие вопросы и сформулируйте рекомендации для проектирования типовых структур данных.
Типовых не существует. Существуют однотипные.
Однако у меня есть советы.
Тут, в Проектировании, меня уже били за то, что я не читал умных книжек и выдаю за свои открытия чужие достижения. На мой взгяд, в качестве советов расстановка копирайтов не важна.
...
Я об этом в ПТ писал. Не буду повторяться. Для поиска: участвовал cat2,
слова "зарождения информации"

optimizer. Как правило, данные никакой структуры вообще не имеют. Структура данных - это отображение естественного представления наших знаний о Мире в мозгу проектировщика базы. Можно - сетевая. Можно - иерархическая. Можно - реляционная. Если отображается реляционной, то возможность решения задачи близка к бесконечности. Если сетевой, то возможность написания близка к нулю, а скорость написания - к бесконечности.
Кстати. У меня есть гипотеза. Любая сетевая база может быть приведена к иерархической введением атрибутов.
Доказательств нет. Есть пример.
Допустим, нам надо создать базу Животных.
Есть животные летающие, есть плавающие, есть ходящие. Нет ничего проще, как создать сетевое представление. Родительские корни - летающие, плавающие и ходящие. Бобр входит в плавающие и ходящие, пеликан во все группы. Кошка входит в ходящие и не любящая плавать.
Типичная каша сетевой структуры. Однако биологи в своей иерархической классификации четко перенесли перенесли "летающие, плавающие, ходящие" в атрибуты и со времен Карла Линея не знают проблем.
Не знают проблем еще и потому, что вопрос: "Сколько животных имеют, как правило, серую окраску, питается растениями, имеет размер не более 50 см и ведут ночной образ жизни?" у них пока, вроде, не задается.

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

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

softwarer
Во-первых, последние дни - чем больше я слушаю людей, тем больше кажется, что попал в какую-то альтернативную реальность.

Во-вторых, "это" рекурсивных запросов не требует.
Надо себя слушать!
Расскажите, как просканировать иерархию в реляционной базе без рекурсивных запросов

kittn2
Расскажите, как просканировать иерархию в реляционной базе без рекурсивных запросов
Имется ввиду не реляционное представление иерархиии, а истинная иерархия, когда в реляционной базе есть таблица родитель-потомок

softwarer kittn2Расскажите, как просканировать иерархию в реляционной базе без рекурсивных запросов
Точно так же, как это уже многие годы делают во всех реляционных базах, лишенных рекурсивных запросов (если верить Вам, их "все кроме одной", если верить мне - малость поменьше, но таки есть).
Для этого нужно перевести иерархию в реляцию. Это всегда возможно в практических базах, так как глубина иерархии может быть четко определена. Кажется, вы не совсем въехали. Иерархия может быть представлена в реляционных базах разными спсобами.
=======
Вопрос на засыпку. Немного искусственный.
Протая иерархическая база - учет наличия компов подразделениях предприятия. Предприятие - иерархическая структура. Управление, отделы, цеха. В цехах - участки. Компы привязаны к Управлению, отделам, участкам. Нет проблем перевести в реляционную. Не проблем отобразить иерархически. Но при иерархическом отображении нужно делать выбор по подвыбранному. Это - рекурсия

softwarer>>Кто Вам это сказал? И как выживают те, кто этого не делает?
Не знаю, вероятно пишут свое "объектное ядро".

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

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

Однако я знаю только один способ представления дерева в реляционных базах при заранее неизвестиной глубине уровней -

CREATE TABLE [dbo].[Node] (
[Node] [int] NULL ,
[ParentNode] [int] NULL ,
ON [PRIMARY]

Это можно сделать. Это работает. Но это такая головная боль!

>>Ну и в чем проблема?
Нет в моем любимом MS SQL рекурсивных запросов. Обход дерева можно сделать курсорами на сервере или курсором на клиенте, но меня рвет от серверных курсоров и клиентской обработки.

=================

Jean K

Jean K >>2 kittn2: насколько мне известно, рекурсией подразумевают другое понятие.
Я, теоритечески знаю, что такое рекурсия в общепринятом понятии. Рекурсивные запросы SQL - отдельная песня. Это когда что-то вроде когда запрос по запросу, пока результат не будет
Я даже примера показать не могу. Ораклоиды лучше расскажут. Кажется, в "большой тройке" только они это смогли сделать.

Jean K >>Иерархию же логически можно представить разными способами, в том числе и таким, при котором рекурсия не понадобится вовсе (RootLevel.SubLevel1.SubLevel2.SubLevel3.....).
Можно. Меня в этом softwarer и укорял. При условии, что заранее известно количество уровней и оно не будет менятся. В сущнности, как я и писал, реляционные базы моделируют деревья удобным для обработки способом

Jean K >>P.S. По пяти вопросам аккредитации "избранных" лично мне непонятно, что мешает любому желающему забраться в ресурсы сети и запостить сюда ответ на любой из поставленных вопросов.

Да не обращайте внимания :). Создатель супер-пупер системы WIM иногда спускается до нас, недостойных, и глашатает Истины. :)

drev kittn2Это можно сделать. Это работает. Но это такая головная боль!

>>Ну и в чем проблема?
Нет в моем любимом MS SQL рекурсивных запросов. Обход дерева можно сделать курсорами на сервере или курсором на клиенте, но меня рвет от серверных курсоров и клиентской обработки.


try CTE in 2005:)
Я 2010 подожду и перейду на 2005 :)