Гость
Целевая тема:
Создать новую тему:
Автор:
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Дерево "типов состояний" / 13 сообщений из 13, страница 1 из 1
21.01.2004, 18:22
    #32383725
Varan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
Есть сущность, которая переходит из состояния в состояние. Каждое состояние характеризуется некой числовой величиной. Состояние характеризуется некой числовой величиной.
Это дело моделируется следующим образом.
Таблица Сущность(ID_Entity...), Таблица Тип_Состояния(ID_Type,Name_Type), Таблица Состояние(ID_Detail,ID_Entyty(FK),ID_Type(FK),Value)
Например, в таблице Сущности находятся люди. В таблице Тип_Состояния след. данные
1 ; Выпивка
2; Развлечения.
Когда структура таблицы Тип_Состояния простая, проблем не возникает и из данных вида
Состояние
1 ;1;1,10
2;1;2,15
3;2;1;15
можно узнать, на сколько было выпито...
Однако, смоделировать следующее:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
                
                                      ->стоимость кружки
               ->попить пивка ->
                                      ->стоимость пива 
выпивка->
                                     ->стоимость кружки
               ->попить воды ->
                                     ->стоимость воды

в вышеприведенной структуре нельзя.
Можно, наверное, сделать таблицу "Тип_состояния" иерархической, но тогда придется хранить в таблице "Состояние" внешний ключ листа дерева, хотя чаще приходится иметь дело с корнями...
Нет ли у кого соображений, какая тут предпочтительнее структура.
...
Рейтинг: 0 / 0
26.01.2004, 11:41
    #32387501
Varan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
Спасибо, ребята, за помощь :-(
...
Рейтинг: 0 / 0
26.01.2004, 13:36
    #32387708
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
А если сделать 5 табл.
Сущность
Тип_Развлечения
Продукт
Продукт_Составляющие_продукта
Составляющие_продукта

Сущность 1-... Продукт
Продукт 1-... Продукт_Составляющие_продукта
Продукт_Составляющие_продукта 1-...Составляющие_продукта
Продукт 1-...Тип_Развлечения

Тогда получится:
Сущность(человеки)
Тип_Развлечения(выпивка, боулинг...)
Продукт(1пиво, 2вода)
Продукт_Составляющие_продукта
(1пиво,1кружка
1пиво,2пиво
2вода,1кружка
2вода,3вода)
Составляющие_продукта(1кружка, 2пиво, 3вода)
...
Рейтинг: 0 / 0
26.01.2004, 15:13
    #32387934
Mik Prokoshin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
Вы бы определились в приведенном примере, где сущности, а где состояния.
IMHO модель :
Сущность:"человек", состояния:"ненапитый","выпимши пивка","выпимши воды"
Сущность:"Кружка", состояния:"полная пива","полная воды","пустая", параметры "стоимость полной пива", "стоимость полной воды", "стоимость пустой"
Соответственно, для отслеживания перехода состояния человека, надо в качестве параметра состояния человека вводить ссылку на состояние кружки. Отсюда легко можно все смоделировать.
Но возможно вводить кроме кружки, отдельные сущности "вода" и "пиво", т.е. задача просто неоднозначно решается.
В итоге, совершенно непонятно, какова должна быть при этом общая логика программы и как к этой логике отнесется пользователь :-)
...
Рейтинг: 0 / 0
26.01.2004, 15:26
    #32387959
Mik Prokoshin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
Если же к сущности "человек" добавлять сущность "выпивка", то какие состояния должны быть у этой "выпивки" ? Например, "Не начатая", "выпить кружку пива", "выпить кружку воды" ? Можно и так (легко найти соответствующие стоимости).
Связи между переходами, в принципе, должны указывать одновременность (связанность) этих переходов. Так что надо определяться с постановкой задачи.

Да, кстати, я использую термин "состояние" так, как привык из работы с автоматами, т.е. это то, что Вы называете "Тип состояния". То, что у Вас называется "состояние", в той теории называется "переход из одного состояние в другое".
...
Рейтинг: 0 / 0
26.01.2004, 15:55
    #32388019
Mik Prokoshin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
>Связи между переходами, в принципе, должны указывать одновременность (связанность) этих переходов.
Читать как "Связи между переходами разных сущностей, в принципе, должны указывать одновременность (связанность) этих переходов."

Т.е. как бы, внутри одной диграммы переходов (для одной сущности), можно просто ограничиться нумерацией. Но если надо связывать несколько диаграмм (для разных сущностей), то надо а) дополнительные линки и б) определить принцип построения автоматной модели.
...
Рейтинг: 0 / 0
26.01.2004, 16:41
    #32388095
Varan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
Mik Prokoshin, bas, большое спасибо, я подумаю, попозже отвечу.
...
Рейтинг: 0 / 0
26.01.2004, 18:43
    #32388278
Varan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
Еще раз попробую переформулировать задачу без слов, вызывающих двусмысленное толкование. Есть сущность и числовая величина, эту сущность характеризующая в определенный момент времени. Причем "тип числа" (То, что я раньше называл "типом состояния") может представлять из себя иерархию.
Раньше , когда "тип числа" был неиерархический, все было просто и отвечать на вопросы типа "какова сумма чисел для таких-то типов чисел и такого-то набора сущностей" было просто.
Теперь число ветевей дерева, задающего "тип числа" неизвестно.
Чтобы не прослыть алкоголиком, приведу пример с лыжами
"Тип чисел" задан деревом
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
 
 -> выпивка
                                                ->прокат горных лыж
                                   ->горные
                                                ->пользование подъемником

                        ->Лыжи 
                                   ->равнинные
 ->развлечения->
                        ->Боулинг  


Причем "детализация" заранее неизвестна. Дерево, ведущее к боулингу, куцее, какие суммы прошли внутри боулинга, не конкретизируются. Дерево, ведущее к "Прокату горных лыж" более развесистое.
В принципе, задачка похожа на ту, что описана в статья "Информационная система и реляционная СУБД"
Там, в частности, есть такая фраза "Я хочу получить баланс, причем не просто по счетам, но и с группировкой по аналитикам. Что-то вроде:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
Товары на складе                             1000 
    Продукты питания                          200 
        Вобла                                  50 
        Пиво  "Lowenbrau"                       150 
    Одежда                                    400 
        Джинсы                                250 
        Майки                                 150 
    Обувь                                     400 
        Кроссовки                             200 
        Ласты на каблуках                     200 

После чего приводит пример решения этой проблемы в варианте с некрасивой структурой. К сожалению, из-за того, что автор пользуется такими терминами как "аналитики", "Z-объекты" вариант с нормальной структурой я так и не понял, и не смог применить подход автора к своей проблеме :-(
...
Рейтинг: 0 / 0
26.01.2004, 19:24
    #32388333
funikovyuri
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
проблема до меня так и не дошла ... :)
...
Рейтинг: 0 / 0
26.01.2004, 21:47
    #32388410
Varan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
funikovyuri,
Видно, я совсем отупел, не могу объяснить, чего хочу. Пора, наверное, отдохнуть :-)
...
Рейтинг: 0 / 0
27.01.2004, 07:32
    #32388507
Mik Prokoshin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
Насколько я понимаю, тогда у Вас задача - отразить иерархическую вложенность измерений а ля OLAP-анализ. Тогда можно предложить два подхода.
1) Максимальное число измерений (это понятие из OLAP, суть аналитика, в общем однородная информация типа "Лыжи", "Боулинг", "Бо(а)бслей" и т.д.) известно, возможные типы измерений известны. Тогда это просто набор справочников и таблица со ссылками на них.

Код: plaintext
1.
2.
3.
4.
Развлечения    Лыжи     горные     прокат    NULL                 // Значения из внешних таблиц-справочников
       ^         ^         ^         ^        ^
       |         |         |         |        |
PK    FK1       FK2       FK3       FK4      FK5        Sum           // Структура таблицы детализации, 
                                                              // в данной записи FK5 не используется, но может быть необходимо для другой иерархии


Так будет максимально делать всяческие выборки и анализ.

2) Максимальное число измерений неизвестно. Тогда только делать древовидную структуру (HierTable) и, если числовые показатели относятся лишь к листам, то выделить их в отдельную таблицу, если же есть смысл их группировать, то можно хранить поле Sum прямо в таблице иерархии.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
  Сущность  1 
      ^
      |
PK    FK        FK_Father                         // Запись HierTable
                    |
                    |      Сущность  2 
                    |            ^
                   \/            |
                   PK            FK      FK_Father                // Другая запись HierTable
                                            |
                                           \/
                                          NULL




При этом "Сущность 1", "Сущность 2" могут быть в разных таблицах (если можно заранее их разделить по таблицам), соответственно, надо определфть набор ключей для связей FK i, либо сущности будут вообще в одной глобальной таблице.
...
Рейтинг: 0 / 0
27.01.2004, 13:19
    #32388992
bas
bas
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
Если понял.... Вернусь к своим "баранам"

Есть 5 табл.
Сущность
Тип_Развлечения
Развлечения (FK(Тип_Развлечения), FK(Составляющие_Развлечения))
Составляющие_Развлечения(FK(Составляющие_Развлечения))- иерархическая
Сущность_Развлечения (FK(Сущность), FK(Развлечения))

Сущность 1-... Развлечения
Развлечения 1-1 Составляющие_Развлечения
Развлечения 1-...Тип_Развлечения
Сущность 1-...Сущность_Развлечения
Развлечения 1-...Сущность_Развлечения

Сущность
(
1чел;
2чел;
)
Тип_Развлечения
(
1выпивка;
2развлеч.;
)
Развлечения (
1лыжи, 1горные, 2развлеч.;
2лыжи, 4равнинные, 2развлеч.;
)
Составляющие_Развлечения(
НУЛЛ,1горные, цена=0р.;
1горные,2прокат горных лыж, цена=10р.;
1горные,3пользование подъемником, цена=10р.;
НУЛЛ,4равнинные, цена=0р.;
4равнинные,5прокат равн. лыж, цена=10р.;
4равнинные,6пользование смазкой, цена=10р.;
)
Сущность_Развлечения
(
1чел,1лыжи;
2чел,2лыжи;
)

Можно в принципе и убрать таблицу "развлечения"... Это уже по желанию
...
Рейтинг: 0 / 0
27.01.2004, 14:18
    #32389122
Varan
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дерево "типов состояний"
bas, спасибо, твоя структура нелоха и вполне могла подойти.
Я остановился на ее упрощенном варианте. Поскольку мне нет особой нужды считать листья отделной сущностью (Mik Prokoshin правльно догадался что мне надо - хоть я и путано объяснял - задача - отразить иерархическую вложенность измерений), я сделал таблицу "Тип_Состояния"("Тип суммы") иерархической, а в таблице создал еще один внешний ключ на ID_Type для хранения идентификатора листа.(Ссылку на корень пришлось оставить из-за соображений совместимости.)
Mik Prokoshin
Спасибо, Вы мне очень помогли.
...
Рейтинг: 0 / 0
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Дерево "типов состояний" / 13 сообщений из 13, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]