Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
Есть сущность, которая переходит из состояния в состояние. Каждое состояние характеризуется некой числовой величиной. Состояние характеризуется некой числовой величиной. Это дело моделируется следующим образом. Таблица Сущность(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. в вышеприведенной структуре нельзя. Можно, наверное, сделать таблицу "Тип_состояния" иерархической, но тогда придется хранить в таблице "Состояние" внешний ключ листа дерева, хотя чаще приходится иметь дело с корнями... Нет ли у кого соображений, какая тут предпочтительнее структура. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2004, 18:22 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
Спасибо, ребята, за помощь :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 11:41 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
А если сделать 5 табл. Сущность Тип_Развлечения Продукт Продукт_Составляющие_продукта Составляющие_продукта Сущность 1-... Продукт Продукт 1-... Продукт_Составляющие_продукта Продукт_Составляющие_продукта 1-...Составляющие_продукта Продукт 1-...Тип_Развлечения Тогда получится: Сущность(человеки) Тип_Развлечения(выпивка, боулинг...) Продукт(1пиво, 2вода) Продукт_Составляющие_продукта (1пиво,1кружка 1пиво,2пиво 2вода,1кружка 2вода,3вода) Составляющие_продукта(1кружка, 2пиво, 3вода) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 13:36 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
Вы бы определились в приведенном примере, где сущности, а где состояния. IMHO модель : Сущность:"человек", состояния:"ненапитый","выпимши пивка","выпимши воды" Сущность:"Кружка", состояния:"полная пива","полная воды","пустая", параметры "стоимость полной пива", "стоимость полной воды", "стоимость пустой" Соответственно, для отслеживания перехода состояния человека, надо в качестве параметра состояния человека вводить ссылку на состояние кружки. Отсюда легко можно все смоделировать. Но возможно вводить кроме кружки, отдельные сущности "вода" и "пиво", т.е. задача просто неоднозначно решается. В итоге, совершенно непонятно, какова должна быть при этом общая логика программы и как к этой логике отнесется пользователь :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 15:13 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
Если же к сущности "человек" добавлять сущность "выпивка", то какие состояния должны быть у этой "выпивки" ? Например, "Не начатая", "выпить кружку пива", "выпить кружку воды" ? Можно и так (легко найти соответствующие стоимости). Связи между переходами, в принципе, должны указывать одновременность (связанность) этих переходов. Так что надо определяться с постановкой задачи. Да, кстати, я использую термин "состояние" так, как привык из работы с автоматами, т.е. это то, что Вы называете "Тип состояния". То, что у Вас называется "состояние", в той теории называется "переход из одного состояние в другое". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 15:26 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
>Связи между переходами, в принципе, должны указывать одновременность (связанность) этих переходов. Читать как "Связи между переходами разных сущностей, в принципе, должны указывать одновременность (связанность) этих переходов." Т.е. как бы, внутри одной диграммы переходов (для одной сущности), можно просто ограничиться нумерацией. Но если надо связывать несколько диаграмм (для разных сущностей), то надо а) дополнительные линки и б) определить принцип построения автоматной модели. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 15:55 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
Mik Prokoshin, bas, большое спасибо, я подумаю, попозже отвечу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 16:41 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
Еще раз попробую переформулировать задачу без слов, вызывающих двусмысленное толкование. Есть сущность и числовая величина, эту сущность характеризующая в определенный момент времени. Причем "тип числа" (То, что я раньше называл "типом состояния") может представлять из себя иерархию. Раньше , когда "тип числа" был неиерархический, все было просто и отвечать на вопросы типа "какова сумма чисел для таких-то типов чисел и такого-то набора сущностей" было просто. Теперь число ветевей дерева, задающего "тип числа" неизвестно. Чтобы не прослыть алкоголиком, приведу пример с лыжами "Тип чисел" задан деревом Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. Причем "детализация" заранее неизвестна. Дерево, ведущее к боулингу, куцее, какие суммы прошли внутри боулинга, не конкретизируются. Дерево, ведущее к "Прокату горных лыж" более развесистое. В принципе, задачка похожа на ту, что описана в статья "Информационная система и реляционная СУБД" Там, в частности, есть такая фраза "Я хочу получить баланс, причем не просто по счетам, но и с группировкой по аналитикам. Что-то вроде: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. После чего приводит пример решения этой проблемы в варианте с некрасивой структурой. К сожалению, из-за того, что автор пользуется такими терминами как "аналитики", "Z-объекты" вариант с нормальной структурой я так и не понял, и не смог применить подход автора к своей проблеме :-( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 18:43 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
проблема до меня так и не дошла ... :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 19:24 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
funikovyuri, Видно, я совсем отупел, не могу объяснить, чего хочу. Пора, наверное, отдохнуть :-) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2004, 21:47 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
Насколько я понимаю, тогда у Вас задача - отразить иерархическую вложенность измерений а ля OLAP-анализ. Тогда можно предложить два подхода. 1) Максимальное число измерений (это понятие из OLAP, суть аналитика, в общем однородная информация типа "Лыжи", "Боулинг", "Бо(а)бслей" и т.д.) известно, возможные типы измерений известны. Тогда это просто набор справочников и таблица со ссылками на них. Код: plaintext 1. 2. 3. 4. Так будет максимально делать всяческие выборки и анализ. 2) Максимальное число измерений неизвестно. Тогда только делать древовидную структуру (HierTable) и, если числовые показатели относятся лишь к листам, то выделить их в отдельную таблицу, если же есть смысл их группировать, то можно хранить поле Sum прямо в таблице иерархии. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. При этом "Сущность 1", "Сущность 2" могут быть в разных таблицах (если можно заранее их разделить по таблицам), соответственно, надо определфть набор ключей для связей FK i, либо сущности будут вообще в одной глобальной таблице. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2004, 07:32 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
Если понял.... Вернусь к своим "баранам" Есть 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лыжи; ) Можно в принципе и убрать таблицу "развлечения"... Это уже по желанию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2004, 13:19 |
|
||
|
Дерево "типов состояний"
|
|||
|---|---|---|---|
|
#18+
bas, спасибо, твоя структура нелоха и вполне могла подойти. Я остановился на ее упрощенном варианте. Поскольку мне нет особой нужды считать листья отделной сущностью (Mik Prokoshin правльно догадался что мне надо - хоть я и путано объяснял - задача - отразить иерархическую вложенность измерений), я сделал таблицу "Тип_Состояния"("Тип суммы") иерархической, а в таблице создал еще один внешний ключ на ID_Type для хранения идентификатора листа.(Ссылку на корень пришлось оставить из-за соображений совместимости.) Mik Prokoshin Спасибо, Вы мне очень помогли. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2004, 14:18 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=32388019&tid=1546652]: |
0ms |
get settings: |
12ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
71ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
51ms |
get tp. blocked users: |
1ms |
| others: | 16ms |
| total: | 181ms |

| 0 / 0 |
