Шаги по созданию хорошо организованной и нормализованной реляционной базы данных

Я только начал создавать базу данных для своего сайта, поэтому я перечитываю Database Systems - Design, Implementation and Management (9th Edition), но я замечаю, что нет единого пошагового процесса, описанного в книге, для создания хорошо организованной и нормализованной базы данных. Книга, кажется, немного повсюду, и хотя процесс нормализации все в одном месте, шаги, ведущие к этому, не являются.

Я думал, что очень полезно иметь все шаги в одном списке, но я не могу найти ничего подобного в Интернете или где-либо еще. Я понимаю, что ответчик, объясняющий все шаги, был бы довольно обширным, но все, что я могу получить по этому вопросу, будет весьма признателен; включая порядок инструкций перед нормализацией и ссылки с предложениями.

Хотя я знаком с процессом, я долгое время занимался разработкой любых баз данных (около 1 года), поэтому я хотел бы, чтобы все было описано подробно.

Меня особенно интересует:

Какой хороший подход приступить к моделированию базы данных (или как перечислить бизнес-правила, чтобы не запутать).

Я хотел бы использовать ER или EER (модель отношений с расширенными объектами), и я хотел бы знать

как правильно подбирать подтипы и супертипы с использованием EER (непересекающихся и перекрывающихся) (а также записывать бизнес-правила для него, чтобы вы знали, что это подтип, если есть общий способ сделать это)

(Я все уже знакомы с процессом нормализации, но ответ может также содержать советы об этом)

По-прежнему нужна помощь:

Записывание бизнес-правил (включая бизнес-правила для подтипов и супер типов в EER)
Как правильно использовать подтипы и супертипы в EER (как их моделировать)

Любые другие предложения будут оценены.

Ответ 1

Я перечитал книгу и некоторые статьи в Интернете и создал короткий список шагов для разработки достойной базы данных (конечно, сначала вам нужно понять основы проектирования базы данных). Более подробно этапы описаны ниже:

(В книге описано много шагов: Database Systems - Design, Implementation and Management (9th Edition), и это то, что ссылаются на номера страниц, но я попытаюсь описать как можно больше и отредактировать этот ответ в следующие дни, чтобы сделать это более полный)

Создайте подробное описание организации операций.
Определите бизнес-правила, основанные на описании операций.
Определите основные сущности и отношения из бизнес-правил.
Перевести сущности/отношения на модель EER
Проверить соглашения об именах
Карта ERR-модели для логической модели (pg 400) *
Нормализовать логическую модель (стр. 179)
Улучшение дизайна БД (стр. 187)
Подтвердить ограничения целостности логической модели (pg 402) (например, длина и т.д.)
Подтверждение логической модели относительно требований пользователя
Перевести таблицы на mySQL-код (в workbench перевести EER в файл SQL с помощью функции экспорта, затем в mySQL)

* вы можете пропустить этот шаг, если используете рабочую станцию и работу модели ER, которую вы там создаете.

1. Подробно расскажите о работе компании. Если вы создаете персональный проект, подробно описывайте его, если вы работаете с компанией, просите документы, описывающие их компанию, а также собеседование с сотрудниками для получения информации (интервью могут генерировать непоследовательную информацию, не забудьте проверить с надзорными органами, какая информация более важна для проектирования )
2. Посмотрите собранную информацию и начните генерировать правила из них, не забудьте заполнить любые информационные пробелы в своих знаниях. Перед тем, как приступить к работе, подтвердите с руководителями в компании.
3. Определите основные сущности и отношения из бизнес-правил. Имейте в виду, что во время процесса проектирования разработчик баз данных не зависит просто от интервью, чтобы определять сущности, атрибуты и отношения. Удивительный объем информации может быть собран путем изучения бизнес-форм и отчетов, которые организация использует в своей повседневной деятельности. (стр. 123)

4. Если база данных сложная, вы можете разбить дизайн ERD на подпоры followig
i) Создание внешних моделей (стр. 46)
ii) Объединить внешние модели с концептуальной моделью (стр. 48)

Follow the following recursive steps for the design (or for each substep) 
    I.   Develop the initial ERD.
    II.  Identify the attributes and primary keys that adequately describe the entities.
    III. Revise and review the ERD.
    IV.  Repeat steps until satisfactory output

You may also use entity clustering to further simplify your design process.

Описание базы данных через ERD: Используйте сплошные линии для соединения слабых сущностей (Слабые объекты - это те, которые не могут существовать без родительской сущности и содержат родителей PK в PK). Используйте пунктирные линии для подключения Сильных Сущностей (Сильные объекты - это те, которые могут существовать независимо от любого другого объекта)

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

6. Логическая конструкция обычно включает перевод модели ER в набор определений отношений (таблиц), столбцов и ограничений.

Переведите ER в логическую модель, используя следующие шаги:

Составить строгие сущности (объекты, которым не нужны другие сущности)
Отношения супертипа/подтипа карты
Показать слабые объекты
Сопоставление бинарных отношений
Сопоставление отношений с более высокими степенями

7. Нормализовать логическую модель. Вы можете также денормализовать логическую модель, чтобы получить некоторые желаемые характеристики. (например, улучшенная производительность)

Уточнить атомарность атрибута - В целом хорошая практика - обратить внимание на требование атомарности. Атомный атрибут - это тот, который не может далее подразделяться. Говорят, что такой атрибут проявляет атомарность. Улучшая степень атомарности, вы также получаете гибкость запросов.
Уточнить первичные ключи, необходимые для гранулярности данных. Гранулярность относится к уровню детализации, представленному значениями, хранящимися в строке таблиц. Данные, хранящиеся на уровень детализации называется атомными данными, как объяснялось ранее. Например, представляйте атрибут ASSIGN_HOURS для представления часов, отработанных данным сотрудником по данному проекту. Однако, эти значения регистрируются на самом низком уровне детализации? Другими словами, ASSIGN_HOURS представляет почасовое общая сумма, суточная сумма, еженедельная общая сумма, ежемесячная сумма или годовая сумма? Очевидно, что ASSIGN_HOURS требует более тщательного определения. В этом случае соответствующий вопрос будет следующим: за какие временные рамки - час, день, неделя, месяц и так что вы хотите записать данные ASSIGN_HOURS? Например, предположим, что комбинация EMP_NUM и PROJ_NUM является приемлемым (составным) первичным ключом в таблице ASSIGNMENT. Этот первичный ключ полезен для представления только общего количества часов работника работал с проектом с самого начала. Использование суррогатного первичного ключа, такого как ASSIGN_NUM, обеспечивает более низкую детализацию и обеспечивает большую гибкость. Например, предположим, что сочетание EMP_NUM и PROJ_NUM используется как первичный ключ, а затем сотрудник заносит две записи "отработанные часы" в таблице ASSIGNMENT. Это действие нарушает требование целостности объекта. Даже если вы добавите ASSIGN_DATE как часть составного ПК, целостность объекта нарушение по-прежнему создается, если какой-либо сотрудник делает два или более записей для одного и того же проекта в тот же день. (The сотрудник, возможно, работал над проектом несколько часов утром, а затем снова работал над ним позже в тот же день.) Тот же ввод данных не вызывает проблем, когда ASSIGN_NUM используется в качестве первичного ключа.
Попробуйте ответить на вопросы: "Кому будет разрешено использовать таблицы и какие части (-ы) таблицы (-ов) будут доступны для пользователей?" ETC.

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

Ответ 2

Я бы порекомендовал вам это видео (около 9) о моделировании E/R

http://www.youtube.com/watch?v=q1GaaGHHAqM

EDIT:

"насколько обширными должны быть диаграммы для этой модели? Должны ли они включать все сущности и атрибуты?"

Да, на самом деле у вас есть ER-моделирование и расширение моделирования ER,

Идея состоит в том, чтобы сделать расширенное моделирование ER, поскольку там вы не только указываете объекты, но также указываете PK и FK и мощность. Посмотрите на ссылку (см. Графику и разницу между обеими моделями).

существует два способа моделирования: один - реальный сценарий, а другой - реальная структура БД, I.E:

Когда вы создаете E-ER Modeling, вы создаете даже отношения и мощность для ВСЕХ сущностей, но когда вы собираетесь создавать БД, нет необходимости создавать отношения с мощностью 1: N (таблица с мощностью N создает FK из таблицы с картой 1, и вам не нужно создавать таблицу отношений в БД), или когда у вас есть мощность 1:1, вы знаете, что одно из ваших объектов может поглотить другой объект.

Посмотрите это Графика, создавались только сущности отношений N: M (когда вы видите 2 или более FK, что таблица отношений)

Но помните, что это просто "правила", и вы можете сломать его, если вам нужен дизайн, для производительности, безопасности и т.д.

о инструментах, их много, но я рекомендовал workbench, потому что вы можете использовать его для подключения к вашим БД ( если вы находитесь в mysql) и создаете моделирование E/R моделирования, с атрибутами, и он будет автоматически создавать таблицы отношений N: M.

ИЗМЕНИТЬ 2:

здесь я помещаю некоторые ссылки, которые могут объяснить, что немного лучше, это займет много строк, и мне будет сложнее объяснить здесь и мной, пожалуйста, просмотрите эти ссылки и сообщите мне, если у вас есть вопросы:

тип и подтип:

http://www.siue.edu/~dbock/cmis450/4-eermodel.htm

бизнес-правила (ограничение целостности)

http://www.deeptraining.com/litwin/dbdesign/FundamentalsOfRelationalDatabaseDesign.aspx (посмотрите, пожалуйста, на этот вопрос, я думаю, это поможет вам со всей этой информацией)
http://www.google.com/url?sa=t&rct=j&q=database%20design%20integrity%20constraints&source=web&cd=1&ved=0CFYQFjAA&url=http%3A%2F%2Fcs-people.bu.edu%2Frkothuri%2Flect12-constraints.ppt&ei=2aLDT-X4Koyi8gTKhZWnCw&usg=AFQjCNEvXGr7MurxM-YCT0-rU0htqt6yuA&cad=rja

Ответ 3

Один из аспектов вашего вопроса касался представления отношений подкласса-суперкласса в таблицах SQL. Мартин Фаулер обсуждает три способа его разработки: мой любимый Наследование классов. Сложная часть заключается в том, что поле Id должно распространяться от суперклассов к подклассам. Как только вы это сделаете, соединения, которые вы, как правило, захотите сделать, являются гладкими, легкими и быстрыми.

Ответ 4

Существует шесть основных шагов при разработке любой базы данных: 1. Анализ требований 2. Концептуальный дизайн 3. Логический дизайн 4. Уточнение схемы 5. Физический дизайн 6. Дизайн приложений и безопасности.