Ответ 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. Нормализовать логическую модель. Вы можете также денормализовать логическую модель, чтобы получить некоторые желаемые характеристики. (например, улучшенная производительность)
8.
-
Уточнить атомарность атрибута - В целом хорошая практика - обратить внимание на требование атомарности. Атомный атрибут - это тот, который не может далее подразделяться. Говорят, что такой атрибут проявляет атомарность. Улучшая степень атомарности, вы также получаете гибкость запросов.
-
Уточнить первичные ключи, необходимые для гранулярности данных. Гранулярность относится к уровню детализации, представленному значениями, хранящимися в строке таблиц. Данные, хранящиеся на уровень детализации называется атомными данными, как объяснялось ранее. Например, представляйте атрибут 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.
Пожалуйста, не стесняйтесь оставлять предложения или ссылки на более качественные описания в комментариях ниже. Я добавлю его к своему ответу.
