Хорошее место для взгляда, например, Проектирований баз данных - [закрытые] Лучшие практики
5 ответов
Прежде чем начать, прочитайте о нормализации до тех пор, пока у вас вообще не останется вопросов по этому поводу. Если вы проходили это только в школе, то, вероятно, вы еще не знаете об этом достаточно для проектирования.
Тщательно соберите требования к каждому модулю. Вам нужно знать:
бизнес-правила (которые специфичны для приложений и которые должны быть реализованы в базе данных, потому что они должны быть реализованы для всех записей независимо от источника),
есть ли юридические или нормативные проблемы (например, HIPAA или требования Sarbanes-Oxley) безопасность (нужно ли шифровать данные?)
Какие данные вам нужно хранить и почему (доступны ли эти данные где-либо еще)
Какие части данных будут иметь только одну строку данных, а какие должны иметь несколько строк?
Как вы собираетесь обеспечить уникальность строки в каждой таблице? Есть ли у вас естественный ключ или вам нужен суррогатный ключ (рекомендуется использовать суррогатный ключ почти во всех случаях)?
Нужна ли вам репликация?
Нужен ли вам аудит?
Как данные будут вводиться в базу данных? Будут ли они поступать из приложения по одной записи за раз (или даже из нескольких приложений) или некоторые из них будут поступать в результате массовой вставки из ETL-инструмента или из другой базы данных.
Нужно ли вам знать, кто и когда ввел запись (весьма вероятно, что это будет необходимо в корпоративной системе.
Какие таблицы поиска вам понадобятся? Ввод данных намного точнее, если вы можете использовать таблицы поиска и ограничить пользователей в значениях.
Какой тип проверки данных вам нужен?
Примерно сколько записей будет в системе? Вы должны иметь представление, чтобы знать, какого размера создавать тестовые данные.
Как вы собираетесь запрашивать данные? Будете ли вы использовать хранимые процедуры, ORM или динамические запросы?
Несколько основных моментов, о которых следует помнить при проектировании. Выберите правильный тип данных для ваших данных. Не храните даты или числа, над которыми вы собираетесь производить математические вычисления, в строковых полях. Храните числа, которые не предназначены для математики (номера деталей, почтовые индексы, номера телефонов и т.д.), как строковые данные, поскольку вам могут понадобиться ведущие нули. Не храните более одной части информации в одном поле. Поэтому не используйте списки, скрепленные запятыми (они указывают на необходимость создания связанной таблицы), и если вы делаете что-то вроде phone1, phone2, phone3, немедленно остановитесь и создайте связанную таблицу. Используйте внешние ключи для обеспечения целостности данных.
На протяжении всего проектирования учитывайте целостность данных. Данные, не обладающие целостностью, бессмысленны и бесполезны. Проектируйте с учетом производительности, это критически важно при проектировании базы данных и НЕ является преждевременной оптимизацией. Базы данных не так легко рефакторить, поэтому важно с первого раза правильно определить наиболее важные части уравнения производительности. Фактически все базы данных должны быть спроектированы для обеспечения целостности данных, производительности и безопасности.
Не бойтесь множественных соединений, правильно проиндексированные соединения будут работать отлично. Не пытайтесь поместить все в таблицу типа "сущность-значение". Используйте их как можно реже. Постарайтесь научиться думать в терминах обработки наборов данных, это поможет вам в разработке. Базы данных оптимизированы для работы с наборами данных.
Есть еще много чего, но этого достаточно, чтобы начать усваивать.
Барри Уильямс опубликовал библиотеку, содержащую около шестисот моделей данных для всех видов приложений. Почти наверняка это даст вам "стартер на десять" для всех ваших подсистем. Доступ к этой библиотеке бесплатный, так что ознакомьтесь с ней .
Похоже, это большое корпоративное приложение, которое нужно вашей организации, и вы, кажется, немного новичок в работе с базами данных. Если это вообще возможно, вы должны начать с одной подсистемы - скажем, Заказы - и заставить ее работать. Строятся не только таблицы базы данных, но и какой-то скелетный интерфейс. Как только это будет достаточно, добавьте еще одну связанную подсистему, такую как Биллинг. Вы же не хотите, чтобы в итоге получился огромный монстр.
Также убедитесь, что у вас есть достойный инструмент моделирования данных. SQL Power Architect достаточно хорош для бесплатного инструмента.
Постарайтесь разделить здесь свои проблемы. Возможность обновления базы данных пользователями - это скорее проблема «дизайна приложения». Если вы правильно поняли дизайн своей базы данных, тогда следует разработать для нее хороший интерфейс.
Первое, на что следует обратить внимание, это Нормализация . Это процесс удаления любых избыточных данных из ваших таблиц. Это поможет поддерживать вашу базу данных в порядке и хранить только ту информацию, которая соответствует вашим потребностям.
Справочник по модели данных.
http://www.amazon.com/Data-Model-Resource-Book-Vol/dp/0471380237/ref=dp_cp_ob_b_title_0
ТЯЖЕЛАЯ штука, но очень хорошо справляется. Всего 3 тома ...
Имеет много очень хорошо проработанных общих структур - но они НЕ легкие, так как охватывают все;) Тем не менее, всегда хорошая отправная точка.
База данных не должна быть моделью. Используется для сохранения информации между сессиями работы.
Вы должны строить свое приложение не на модели данных, а на хорошей объектно-ориентированной модели , которая следует бизнес-логике.
Когда ваша объектная модель готова, подумайте о том, как вы можете сохранить и загрузить ее вместе со всем дизайном базы данных, который с ней связан.
(но, видимо, ваша компания просто хочет, чтобы вы спроектировали базу данных? Не приложение?)