ERD черновик для создания списка сборных данных

Question

Это вопрос для обсуждения Table design about sets of data collection elements, поскольку я все еще пытаюсь придумать дизайн.

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

Любые мысли/обратная связь помогут.

EDIT

@YoungBob Прежде всего, большое спасибо за ваш вклад. FormId (PK) также является внешним ключом для DataCollectionId, поэтому я могу запросить таблицы с одинаковым идентификатором DataCollection.DatacollectionId = Form.FormId, чтобы получить оба атрибута уровня, нет?

Я не буду предоставлять интерфейс для создания этих форм «на лету», поэтому я не хотел включать разделы или типы вопросов, но мне понравилась идея включения контроля версий.

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

Поскольку я разместил вопрос, я добавил ссылку для DataCollectionIntervals, как вы предложили таким образом - это выглядит намного лучше?

http://imageshack.us/f/716/erd02.png/

Answer 1

дизайн схема выглядит хорошо для меня, по крайней мере, на основе информации, которую вы дали в этом и предыдущем посте. Лучшая практика - начать с нормализованного дизайна, а затем де-нормализовать, где, по вашему мнению, требуется оптимизация запросов. Я предполагаю, что база данных не будет массивной или иметь высокий уровень транзакций, поэтому производительность не должна быть проблемой, поэтому я бы придерживался нормализованного дизайна. Как правило, денормализация может быть целесообразной, если вам нужно писать запросы, которые объединяют более 4 таблиц (по крайней мере, в sql-сервере), но я не могу видеть, что это происходит с этим дизайном схемы.

Как вы можете предположить в своем вопросе, таблицы формы и образца могут быть кандидатами на денормализацию, включая атрибуты для обеих в таблице DataCollection, но это будет зависеть от того, сколько других атрибутов Form и Sample имеют и сколько из них являются общими для обоих ,

Один совет, который я бы дал, - это рассмотреть вопрос о том, чтобы предоставить таблице формы первичный ключ, который является короткой символьной строкой, если у вас есть довольно стандартные формы, которые, как я считаю, облегчают жизнь при просмотре таблиц (например, немного напоминает формы HMRC P45 , P60 и т. Д. Или коды аэропортов LHR, JFK и т. Д.), Так как вам не нужно продолжать присоединяться к другим таблицам, чтобы помнить, к какой форме относится конкретный идентификатор int. Поле CHAR (3) также использует меньше памяти, чем INT. Это может относиться к другим таблицам, таким как DataCollectionType. Но это, вероятно, вопрос личных предпочтений.

Из нашего обсуждения в предыдущем столбце таблица данных DataFrequency, о которой мы говорили, вероятно, должна быть ссылкой «много-1» в таблице DataCollection. Возможно, DataCollectionIntervals может быть лучшим именем для него.

Еще одна вещь, о которой стоит подумать в дизайне, заключается в том, выиграют ли таблицы с частой доступностью до вертикального разделения. Под этим я имею в виду, если таблица имеет широкие ряды, т.е.множество атрибутов или голодных атрибутов хранения, таких как VARCHAR (MAX), которые редко доступны, можно разделить на отдельную таблицу со ссылкой 1-1, которая может значительно улучшить производительность запросов, связанных с этой таблицей. Но, как я уже сказал, я не вижу, чтобы производительность была проблемой с размером базы данных, которую вы планируете, и предполагая, что вы будете использовать что-то вроде SQL Server.

И последнее: структура Forms может быть немного сложнее, чем схема в настоящее время указывает, например, формы обычно разбиваются на несколько разделов, и требуемые типы вопросов могут быть довольно сложными, например. множественный выбор, текст, ветвление, условный. Также формы могут существовать в разных версиях (используйте флаг «Актив» для идентификации текущей активной версии в таблице «Формы»). Я посмотрел на использование самого queXML для разработки вопросника в XML, но решил, что он немного переборщил за то, что мне было нужно, поэтому я решил использовать более простую схему XML, которая может быть импортирована в базу данных.