Материал для чтения базы данных

Question

Я уверен, что это было бы задано раньше, но я очень смущен!

Скажем, у меня есть БД SQL Server, который содержит следующие таблицы

и данные ...

INSERT [dbo].[Organisation] ([id], [name]) VALUES (1, N'ABC Ltd') 
INSERT [dbo].[Organisation] ([id], [name]) VALUES (2, N'XYZ Ltd') 

INSERT [dbo].[Employee] ([id], [name], [organisationId]) VALUES (1, N'Dave', 1) 

INSERT [dbo].[Message] ([id], [text], [employeeId], [created]) VALUES (1, 'My 1st message', 1, '2012 01-01 00:00:00') 
INSERT [dbo].[Message] ([id], [text], [employeeId], [created]) VALUES (2, 'My 2nd message', 1, '2012 01-02 00:00:00') 
INSERT [dbo].[Message] ([id], [text], [employeeId], [created]) VALUES (3, 'My 3rd message', 1, '2012 01-03 00:00:00') 

Таким образом, мы можем видеть, что Дэйв, человек, который работает для ABC Ltd, создал 3 сообщения в течение 3 последовательных дней. Все хорошо в мире.

Если окажется, что Дэйв никогда не работал в ABC Ltd, но на самом деле работает для XYZ Ltd, это нормально, мы меняем идентификатор организации и все.

Что, однако, следует делать, если он работал на ABC, но затем был изменен на XYZ Ltd в 2012-01-02.

Любой отчет, в котором спрашивают, сколько сообщений было поднято каждой организацией, будет работать, если вы запустите день до того, как мы изменим организацию Daves OrganisationId, покажем 100% для ABC и 100% для XYZ, если они будут запущены на следующий день. Неправильно, неправильно, неправильно!

Мой вопрос не для кого-то, чтобы решить эту загадку, но назовите меня в направлении тем, которые я мог бы смотреть, что могло мне помочь.

Я сегодня нахожусь в поиске следующих терминов «Хранилище данных», «Системы, основанные на времени» и «Временные базы данных», и прочитал некоторые очень запутанные статьи (сбив с толку для меня, я уверен, что они отличные статьи).

Итак, может ли кто-нибудь помочь мне, подталкивая меня в правильном направлении? Я уверен, что вы можете собрать из этого сообщения, что мне нужен «для манекенов» руководство к теме ..... что бы это ни было!

Cheers.

Answer 1

Что, однако, следует делать, если он работал на ABC, но затем был изменен на XYZ Ltd в 2012-01-02.

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

Начало статьи в этой википедии Data Normalization. Поиск изображений Google для «отношений многих и многих». Изображения приведут вас к некоторым хорошим объяснениям.

Answer 2

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

Это НЕ денормализация по мере изменения данных со временем. Так, например, если у меня есть сообщение о том, что мне нужно знать, какая организация его отправила и какой сотрудник отправил его, тогда мне нужно сохранить оба в таблице сообщений и не отвечать на соединение между сотрудником и организацией (что мне, вероятно, понадобится знать для других вещей.)

Для некоторых вещей вы даже не хотите хранить поле id в финальной таблице, кроме фактических текстовых данных.Таким образом, вы можете захотеть сохранить имя сотрудника и название организации, а также идентификаторы в таблице сообщений, если вам нужно сообщить об имени организации (или лица), как это было в момент отправки сообщения. Это кажется менее вероятным с сообщениями, чем с некоторыми другими вещами, поэтому позвольте мне привести пример, у вас есть приложение для заказа. В таблице сведений о заказе вы не хотите хранить только партию part_number, но вы также хотите сохранить имя части (это может измениться с течением времени, но когда у клиента возникнут вопросы, он будет смотреть на документы, которые вы послал его в то время) и цена (которая почти наверняка изменится с течением времени) и, возможно, другие детали. Вы также можете сохранить PK для части, чтобы вы могли легко найти ее прямо сейчас и посмотреть, сколько стоит замена, например.

Answer 3

Я видел, как эта проблема возникала несколько раз за эти годы. Это неспособность признать, что «это то, где Дейв работает прямо сейчас (или последний раз, когда мы проверяли)» - это другое отношение, которое «Это часть истории работы Дейва». Отношение истории работы является состоятельным, потому что каждая ассоциация имеет дату начала и дату окончания. В первый раз, когда я увидел, что эта модель дизайна была связана с системой членства в клубе здоровья.

Очевидно, что вы не хотите запрашивать данные сообщений, используя отношения «где Дейв работает прямо сейчас». Я могу подумать о двух способах решения ближайшей проблемы: либо связать сообщение напрямую с компанией, либо следовать истории работы, чтобы получить компанию. На практике я видел, что этот последний подход усложняется; если вы решите пойти по этому маршруту, убедитесь, что вы получаете что-то от него с точки зрения данных, о которых вы заботитесь. Определенно вам следует подумать о том, чтобы принять простое решение и просто зафиксировать прямые сообщения/отношения с компанией, которые, как вы знаете, вас волнуют. Это также позаботится о случае, когда Дэйв подрабатывает.

Answer 4

Вот очень простой способ смоделировать эту ситуацию:

По сути, вы зафиксируете сообщение не на работника (лица), но в определенный период работы. Это нормально работает, если:

• Безработный никогда не может быть связан с сообщением.
• Вы довольны соблюдением временных отношений на уровне приложений. Например, Message.Created должен находиться внутри соответствующих EmploymentStartDate и TerminationDate, но сама база данных не будет обеспечивать ее выполнение (по крайней мере, не декларативно).