Гость
Войти | Профиль | Очистить
Целевая тема:
Создать новую тему:
Автор:
Действия ...
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Хронологичность данных / 13 сообщений из 13, страница 1 из 1
28.11.2009, 14:19
    #36336945
Umberto_Eco
Umberto_Eco
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
Всем привет!

Хочу спросить совета у опытных людей. Именно совет, а не сделать за меня. ))
Допустим есть структура
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
CREATE TABLE Work(
	ID int NOT NULL,
	Name varchar( 50 ) NOT NULL,
	constraint PK_Work primary key(ID)
);

CREATE TABLE Worker(
	ID int NOT NULL,
	idWork int NULL,
	Name varchar( 50 ) NOT NULL,
	constraint PK_Worker primary key(ID),
	constraint FK_Worker_Work foreign key(idWork) references Work(ID)
);
И тестовые данные
Код: plaintext
1.
2.
3.
4.
5.
6.
insert into Work(ID, Name) values( 1 , 'Банк');
insert into Work(ID, Name) values( 2 , 'Министерство');
insert into Work(ID, Name) values( 3 , 'ЖЭК');
insert into Work(ID, Name) values( 4 , 'безработный');

insert into Worker(ID, idWork, Name) values( 1 ,  1 , 'Вася');
insert into Worker(ID, idWork, Name) values( 2 ,  1 , 'Федя');
Сразу оговорюсь - это лишь модельный пример. Проблема приблизительно такая. Допустим, Вася работает в "ЖЭК" (idWork=3) с 01.01.1995 по 31.12.1997. Потом меняет место работы на "Министерство" (idWork=2) где трудится с 01.01.1998 по 10.07.1998. А потом уходит в "Банк" 11.07.1998, где и трудится по настоящее время. Как это все изобразить? Да так, чтобы потом запросы были по возможности менее напряжными для сервера. За эту "хронологичность" надо платить, я понимаю, но хотелось бы поменьше. )))

На первый взгляд самым простым выходом будет изменить тип связи между Work и Worker на "многие-ко-многим" и в таблице связей хранить период действия той или иной записи справочника Work для Worker. Но хотелось бы посоветоваться с общественностью: кто и как решает такие задачи?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
28.11.2009, 18:56
    #36337114
П-Л
П-Л
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
Таблица организаций (работ), таблица физлиц, справочник должностей, таблица кто когда в какой должности работал - id организации, id физлица, id должности, дата с, дата по (может быть открыта если еще не перешел дальше)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.11.2009, 07:24
    #36337363
Roman S. Golubin
Roman S. Golubin
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
Umberto_Eco
Что надо делать с совместителями? Вася работает Министерстве и отмывает левые доходы, заработанные в Министерстве через Банк (работает там по совместительству). Что делать?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
29.11.2009, 13:07
    #36337497
Umberto_Eco
Umberto_Eco
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
Roman S. GolubinUmberto_Eco
Что надо делать с совместителями? Вася работает Министерстве и отмывает левые доходы, заработанные в Министерстве через Банк (работает там по совместительству). Что делать?Совмещение нескольких работ - нормальное явление, конечно. Пример взят от фонаря, честно говоря. Учет мест работы - не мой профиль. )

Предыстория такова. Я столкнулся со следующей ситуацией. Функционирует система учета услуг. Отчеты зависят от разнообразных атрибутов сущности "Персона". К примеру "занятость", отсюда и пример вобщем-то. Или социальный статус. Понадобилось сделать отчет повторно спустя более года. За это время некий Вася сменил статус с "безработный", скажем, на "пенсионер". И естественно итог сделанный через год отличался от сделанного неделю назад. Ну, понятное дело протокол изменений просмотрели, причину выяснили. Но меня вопрос хронологической согласованности заинтересовал.

Есть и другие ситуации. Человек меняет фамилию. Ему оказываются некие услуги. Требуется знать, что на момент оказания услуги1 он был Вася, а на момент оказания услуги2 стал Кондратием. Как-то так. Решение для отдельных ситуаций придумать несложно. Но подозреваю, что требуется системный подход к разработке архитектуры БД. То, что предложил П-Л я говорил в последнем абзаце первого сообщения. Интересен чужой опыт. Кто, как и почему. )

ЗЫ. Читаю Дейта на сей предмет, но что то пока тяжело дается
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.11.2009, 11:37
    #36338471
-------------------------
-------------------------
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
Developing Time-Oriented Database Applications in SQL
RICHARD T. SNODGRASS

Contents
Foreword by Jim Gray vii
Foreword by Jim Melton ix
Preface xvii
1 Introduction 1
1.1 A Triad of Triples 2
1.2 The SQL Standard 4
1.3 Conventions 5
1.4 Implementation Considerations 7
1.5 Readings 8
2 Fundamental Concepts 11
2.1 Valid-Time State Tables 12
2.2 Transaction-Time State Tables 18
2.3 Bitemporal Tables 20
2.4 Summary 22
2.5 Readings 23
3 Instants and Intervals 25
3.1 Instants 26
3.2 Intervals 30
x i i CONTENTS
3.3 Predicates 33
3.4 Constructors 36
3.5 Implementation Considerations 42
3.6 The Year 2000 Problem* 63
3.7 Subtleties* 74
3.8 Implementation Considerations* 83
3.9 Summary 84
3.10 Readings 85
4 Periods 89
4.1 Literals 90
4.2 Predicates 90
4.3 Constructors 93
4.4 Implementation Considerations 97
4.5 Summary 108
4.6 Readings 108
5 Dening State Tables 111
5.1 Initial Schema 112
5.2 Adding History 113
5.3 Temporal Keys 117
5.4 Handling Now 119
5.5 Uniqueness Reexamined 121
5.6 Referential Integrity 126
5.7 Constraint Attributes* 131
5.8 Implementation Considerations 132
5.9 Summary 139
5.10 Readings 140
6 Querying State Tables 143
6.1 Extracting the Current State 143
6.2 Extracting Prior States 145
CONTENTS x i i i
6.3 Sequenced Queries 145
6.4 Nonsequenced Variants 156
6.5 Eliminating Duplicates 158
6.6 Implementation Considerations 169
6.7 Summary 173
6.8 Readings 174
7 Modifying State Tables 177
7.1 Current Modications 177
7.2 Sequenced Modications 188
7.3 Nonsequenced Modications 197
7.4 Modications That Mention Other Tables* 198
7.5 Temporal Partitioning* 206
7.6 Implementation Considerations 213
7.7 Summary 215
7.8 Readings 216
8 Retaining a Tracking Log 219
8.1 Dening the Tracking Log 220
8.2 Queries 222
8.3 Modications 229
8.4 Permitting Insertions 230
8.5 Backlogs 233
8.6 Using After-Images Consistently 235
8.7 Transaction Semantics* 240
8.8 Renements* 243
8.9 Implementation Considerations 244
8.10 Summary 248
8.11 Readings 250
9 Transaction-Time State Tables 253
9.1 Denition 254
9.2 Maintenance 255
x i v CONTENTS
9.3 Queries 259
9.4 Temporal Partitioning* 262
9.5 Vacuuming* 268
9.6 Implementation Considerations 272
9.7 Summary 273
9.8 Readings 275
10 Bitemporal Tables 277
10.1 Denition 278
10.2 Modications 282
10.3 Queries 307
10.4 Integrity Constraints 323
10.5 Temporal Partitioning* 329
10.6 Vacuuming* 337
10.7 Implementation Considerations 339
10.8 Summary 339
10.9 Readings 340
11 Temporal Database Design 343
11.1 Properly Sequencing the Design 343
11.2 Conceptual Design 345
11.3 Logical Design 355
11.4 Physical Design 375
11.5 Advanced Design Aspects* 377
11.6 Benets 382
11.7 Application Development 383
11.8 Implementation Considerations 396
11.9 Summary 397
11.10 Readings 397
CONTENTS xv
12 Language Directions 401
12.1 SQL-92 401
12.2 SQL-92 Limitations 401
12.3 SQL3 402
12.4 Periods 403
12.5 Dening Valid-Time State Tables 406
12.6 Querying State Tables 411
12.7 Modifying State Tables 416
12.8 Retaining a Tracking Log 421
12.9 Transaction-Time State Tables 426
12.10 Bitemporal Tables 427
12.11 Capstone Case 437
12.12 Migration 446
12.13 Additional Constructs of SQL3* 455
12.14 Implementation Considerations 457
12.15 Summary 460
12.16 Readings 465
13 Prospects 469
Glossary 471
Bibliography 479
Author Index 485
Subject Index 487
About the Author 502
About the CD-ROM 503
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.11.2009, 17:26
    #36339515
Фёдоров
Фёдоров
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
Developing Time-Oriented Database Applications in SQL (in PDF)
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.11.2009, 17:43
    #36339559
Umberto_Eco
Umberto_Eco
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
Федоров, аноним,

Спасибо большое. Попробую разобраться с творением Снодграсса.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.11.2009, 22:30
    #36339876
SERG1257
SERG1257
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
В двух словах - если контроль над приложением полный (новое приложение) то

1 в таблицу добавляется пара полей dfrom, dto, плюс триггеры отслеживающие дыры/пересечения.
2 Текущую дату можно делать либо null (красившее) либо волшебная дата в будущем типа 01-01-9999 (проще в реализации).
3 во ВСЕ запросы вводится условие :query_date between dfrom and dto (или dfrom<=:query_date and :query_date<dto)
4 Одна из дат (лучше dto) добавляется в индексы

Для существующего приложения условие 3 как правило самое трудновыполнимое, поэтому применяют другой подход.
1 вводят дополнительную таблицу - история изменений параметра Х со всеми причиндалами из пунктов 1 - 4 выше
2 пишут триггер чтобы сохранял изменения параметра Х
3 в исторических запросах параметр Х берут из таблицы истории, а не базовой таблицы
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
30.11.2009, 22:54
    #36339902
Umberto_Eco
Umberto_Eco
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
SERG1257,

После беглого прочтения Снодграсса больше склоняюсь к таблицам состояния, т.е. вынести изменяющиеся во времени атрибуты сущности в отдельную таблицу. Единственное, что смущает, что на каждый "чих" в виде изменения одного атрибута необходимо добавлять новую запись. Повторения много. Может EAV задействовать? Хотя... имеются опасения, что найдутся какие-нибудь грабли. Особенно учитывая, что с EAV для больших таблиц не работал.

P.S. А изменением логики существующего приложения проблем больших не ожидается, потому что все запросы через хранимки проводятся.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.12.2009, 00:14
    #36339984
SERG1257
SERG1257
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
Umberto_Eco вынести изменяющиеся во времени атрибуты сущности в отдельную таблицу.То бишь пойти по первому пути добавив две даты.
Umberto_Eco что на каждый "чих" в виде изменения одного атрибута необходимо добавлять новую запись. Зато читается быстро, а место на диске нынче дешево.
Umberto_Eco Повторения много. Для таких быстроменяющихся атрибутов можно воспользоваться вторым путем.
Umberto_Eco Может EAV задействовать? Хотя... имеются опасения, что найдутся какие-нибудь грабли.Грабля там одна, но большая - производительность просаживается капитально
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.12.2009, 09:17
    #36340258
Umberto_Eco
Umberto_Eco
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
SERG1257,

Благодарю. Попробую описанный мною выше подход. Будет время - отпишусь как это выглядит на схеме.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
01.12.2009, 09:42
    #36340302
Naf
Naf
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
вот Шаблон: Периодические сведения
Здесь персона - измерение
ее состояние - ресурс
Персоны и состояния естественно отдельные таблицы
С уважением, Naf
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
17.01.2010, 16:39
    #36414582
Umberto_Eco
Umberto_Eco
Гость
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Хронологичность данных
Как и обещал делюсь "успехами" в проектировании time-oriented баз данных.

Во-первых, повторно большое спасибо за ссылку на труд Снодграсса мемберу Федорову. Книга дала много пищи для ума. Английский непрост (лично для меня), но форма изложение очень даже импонирует.

После более вдумчивого прочтения. Из трех подходов к проектированию мои изначальные цели решаемы полностью, пожалуй, только с использованием bitemporal tables, совмещающего версионирование во времени и протоколирование изменений. Но этот подход сложнее. Пока решил остановиться на valid-time state tables.

Не претендую на оригинальность. Уверен эта тема обсуждалась не раз. Ссылка Naf подтверждает, что тема не нова. Но указанный топик слишком абстрактен и слабо аргументирован на практике.

Приведу образчик кода (T-SQL, MSSQL2008)
 
Фрагмент кода
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
use tempdb
go

if object_id('Person', 'U') is not null
	drop table Person

CREATE TABLE Person(
	idPerson int not null identity,
	Name varchar( 40 ) not null,
	StartDate date not null,
	EndDate date not null default '99990101',
	constraint PK_Person primary key(idPerson, EndDate),
);
go

if object_id('Person_UPD_ts', 'P') is not null
	drop proc Person_UPD_ts
go

-- time-sequenced modifications according to [Snodgrass2000]
create procedure Person_UPD_ts
	@idPerson int,
	@Name varchar( 40 ),
	@EndDate date = null output
as
begin
	set nocount on;
	
	declare @idPerson_vt int, @EndDate_vt date
	
	select
		@idPerson_vt = idPerson,
		@EndDate_vt = EndDate
	from Person with(rowlock, xlock)
		-- table hints play the role of "critical section" for consistency 
		-- (nonintersecting valid-time state ranges)
	where idPerson = @idPerson and EndDate = '99990101';
	
	if (@idPerson_vt is not null) begin
		-- editing expiration date of previous state
		update Person set 
			EndDate = getdate()
		where idPerson = @idPerson_vt and EndDate = @EndDate_vt;
	end;
	
	-- new time state
	set identity_insert Person on;
	set @EndDate = '99990101'
	insert into Person(idPerson, Name, StartDate, EndDate)
	values(@idPerson, @Name, getdate(), @EndDate);
	set identity_insert Person off;
	
end
Это, конечно, сильно упрощен и представляет собой вырезки из реального кода.

К чему это я? Предлагаю свою тему для обсуждения вопросов по разработке time-oriented баз данных. Начнем?

Вопросы:
1) Безопасна ли схема изменения атрибутов сущности, приведенная выше в случае MSSQL в режиме "чистого" версионника?
2) При размышлениях пришел к предварительному выводу, что среди СУБД "верисонники" не смогут гарантировать непересекаемость интервалов действия (прошу прощения за кустарную терминологию). Это при том, что мне версионники нравились больше. Прав ли я?
3) Надежные способы обеспечения непересекаемости интервалов действия без поддержки декларативного объявления (таковых в SQL не имеется пока)?
4) В работе Снодграсса используется проверка на CHECK-ограничениях. Надежна ли она?


Выскажите свои соображения по этому поводу, пожалуйста. Интересно обменяться мнением.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Хронологичность данных / 13 сообщений из 13, страница 1 из 1
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение  
Полит. конфиден.  
созд. / загр.: 493ms
Закрыть
start [/forum/topic.php?fid=32&mobile=1&tid=1542886]:
 0ms
get settings:
 9ms
get forum list:
 19ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 165ms
get topic data:
 7ms
get forum data:
 4ms
get page messages:
 41ms
get tp. blocked users:
 1ms
others: 243ms
total:  493ms
x
x
Закрыть


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