Схема таблицы базы данных и совокупные корни

Question

Приложение - однопользовательский, 1-уровневый (1 шт.), База данных SqlCE.Уровень DataService будет (я думаю): репозиторий, возвращающий доменные объекты и запрашивающий базу данных с помощью LinqToSql (dbml).Очевидно, столбцов гораздо больше, это упрощенное представление.

LogTime в отдельной таблице: http://i53.tinypic.com/9h8cb4.png

LogTime в таблице ItemTimeLog (как время): http://i51.tinypic.com/4dvv4.png

альтернативный текст http://i53.tinypic.com/9h8cb4.png

Это моя первая попытка создания базы данных> 2 таблиц.Я думаю, что схема таблицы имеет смысл, но мне нужно некоторое подтверждение или критика.Потому что отношения за столом выглядят довольно страшно, если честно.Я надеюсь, что вы могли бы;

• Посмотрите на схему таблицы и ответьте, если есть явные признаки проблем или ошибок, которые вы сразу заметите .. И если у вас есть время,

• Посмотрите на сводку / вопросы программы и посмотрите, имеет ли смысл таблица для этих пунктов.

Пожалуйста, будьте жестоки, япопытаюсь защитить :)

Краткое содержание программы:

a) Набор категорий, каждая из которых имеет набор стратегий (1: m)

b) Каждый день будет производиться несколько изделий.И каждая стратегия МОЖЕТ ссылаться на нее.(Таким образом, может быть 50 элементов, и стратегия может ссылаться на 23 из них)

c) На элемент может ссылаться более чем одна стратегия.Поэтому я думаю, что это отношение m: m.

d) Значения состояния будут регистрироваться с фиксированными долями времени в течение дня, для: - .... каждой стратегии .....each StrategyItem .... каждый элемент

e) Действие над элементом может выполняться стратегией, которая ссылается на него.- Это зарегистрировано как ItemAction (могло бы называться StrategyItemAction)

User Requsts

b) -> e) описал основной режим активности программы.Для работы только с сегодняшним DayLog , для каждой категории. 2-й приоритет активность: поиск истории , которая обычно будет из всех категорий, начиная со дня x и заканчивая днем ​​y;Получить все StrategyDailyLog.

Вопросы

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

2. StrategyItem создан для представления отношения m: m.Это правильно, как я отметил 1: m / 1: 1 (отмечено красным)?

3. StrategyItemTimeLog и ItemTimeLog;Регистрирует значения, которые оба должны быть извлечены вместе, при получении StrategyItem.Причина, по которой я отделился, заключается в том, что первая стратегия зависит от стратегии, и несколько стратегий могут ссылаться на один и тот же элемент.Поэтому я подумал не дублировать те значения, которые не зависят ни от стратегии, а только от предмета.Поэтому я также вытащил LogTime, поскольку он, кажется, является единственным параметром, объединяющим журналы.Но это все выглядит довольно тревожно с этими 3 таблицами.Имеет ли это смысл вообще?Или у вас есть предложение?

4. Розовые круги показывают мою смутную попытку Совокупных корневых путей.Я думал с точки зрения «какая сущность отвечает за удаление».Хотя я не уверен насчет фактического корня.Я думаю, что это категория.Имеет ли смысл иметь отношение к запросам пользователя , описанным выше?

---

EDIT1: (Обновленная схема, показывающая типичное количество элементов иерархии для первых нескольких отношений, за 365 дней и дополнительные пояснения)

1: 1 отношение: Извините.Я допустил ошибку.StrategyDailyLog должен быть 1: m.Смотрите обновленную схему.Это один на Стратегию в день.

DayLog / StrategyDailyLog: Я размышлял над тем, будет ли DayLog частью иерархии, подобной этой или нет. Назначение таблицы DayLog - хранить «суммы значений», полученные из всех таблиц StrategyDailyLog, за один и тот же день. Как и показатели производительности за этот день. Он также содержит значение даты. Что позволяет мне опустить значение даты в StrategyDailyLog (что, я думаю, было бы как бы дублированием моделирования поля даты), но вместо этого существует ссылка на DayLog, чтобы «найти» дату. Я не уверен, является ли это злоупотреблением / неправильным представлением о нормализации.

Нулевое значение: Я не думал об этом. Я считаю, что нашел 2, как теперь отмечено в StrategyDailyLog и ItemAction. Они не могут быть нулевыми при создании, но их можно установить равными нулю, если нужно удалить либо Strategy, либо StrategyItem. Это не должно требовать удаления StrategyDailyLog и ItemAction. Следовательно, они могут быть установлены в нуль.

Все Id-столбцы: Моя идея состояла в том, чтобы иметь идентификатор (автоматически сгенерированный Integer) в качестве PK для всех моих таблиц. Я полагал, что этого также будет достаточно в качестве ключа кандидата. Разве это не правильный способ сделать ПК? Это единственный способ определить любую мою таблицу. Я задавал вопрос раньше, если это нормально, может быть, я неправильно понял, но подумал, что это хороший подход.

отношение m: m: Это то, что я пытался сделать: StrategyItem - это таблица m: m StrategyDailyLog / DailyItem.

Answer 1

Хорошо. Вот я жестокий. Я не понимаю модель. Поэтому, вместо того, чтобы пытаться так много комментировать, вот некоторые мысли, которые пришли мне в голову, когда я посмотрел на это.

Я думаю, вы должны взглянуть на свои отношения 1: 1 (все они). Почему DayLog и StrategyDailyLog разделены на две таблицы? Возможно, потому что у вас всегда будет хотя бы один элемент DayLog, но не все элементы DayLog имеют элемент StrategyDailyLog. В этом случае вы можете использовать StrategyID FK в таблице DayLog с параметром allow nulls.

Было бы полезно понять модель, если бы вы могли показать, какие поля являются обязательными и какие поля принимают значение NULL в качестве значения.

Все ваши таблицы имеют собственный столбец идентификаторов. Это может быть довольно запутанным, когда вы делаете отношения 1: 1 и отношения m: m. Для отношения 1: 1 обычно связь между двумя таблицами выполняется по первичному ключу в обеих таблицах. Если вы этого не сделаете, вам нужно создать ключ-кандидат в столбце внешнего ключа. В вашем случае это означает, что у StrategyDailyLog должен быть ключ-кандидат на DayLogID.

Отношение m: m между двумя таблицами обычно решается путем добавления новой таблицы между ними с первичными ключами из обеих таблиц. Эти поля вместе являются первичным ключом для таблицы в середине. Скажем, например, что у вас должно быть отношение m: m между категорией и стратегией. Затем вы должны создать таблицу с именем CategoryStrategy с двумя полями CategoryID и StrategyID, которые вместе являются первичным ключом для таблицы CategoryStrategy.

Я надеюсь, что мои комментарии имеют смысл и что они полезны для вас.

РЕДАКТИРОВАТЬ 2011-01-17

Я не думаю, что в качестве принципа вы должны использовать столбец IDENTITY в качестве первичного ключа во всех таблицах. Отношение m: m не нуждается в этом, поэтому вы не должны этого делать. Я также думаю, что вы неправильно поняли, что я имел в виду под ключом-кандидатом. Ключ-кандидат - это ключ, который мог бы использоваться в качестве первичного ключа. В MS SQL Server вы определяете УНИКАЛЬНОЕ ОГРАНИЧЕНИЕ для ключа-кандидата. Пример: Таблица StrategyItem имеет идентификатор PK, но комбинация StrategyID и DailyItemID является ключом-кандидатом. Лучше было бы удалить идентификатор и использовать StrategyID + DailyItemID в качестве PK.

Ниже приведена схема, которую я построил бы с вашим описанием. Я мог пропустить что-то важное, потому что я не знаю всего о том, что вы хотите сделать. Вы не должны так много думать о производительности запросов и построении агрегатов при разработке схемы. Это можно сделать, создав индексы по столбцам и используя суммы, числа и группировки в ваших запросах. Индекс для столбца, созданного в приведенной ниже модели, будет необходим для ваших запросов по дате или интервалу дат. В MS SQL Server есть нечто, называемое кластерным индексом. По умолчанию PK таблицы является кластеризованным индексом, но в этом случае я бы сделал индекс по столбцу Created кластеризованным индексом.

Категория имеет 0,1 или более стратегий. LogItem имеет категорию и, возможно, одну стратегию LogItem.Created содержит дату и время.