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

Question

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

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

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

Я особенно заинтересован в:

• Что хороший подход, чтобы начать моделирование базы данных (или как список бизнес-правил, поэтому его не сбивает с толку)

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

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

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

все еще нужна помощь:

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

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

Answer 1

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

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

1. Создайте подробный рассказ об описании деятельности организации.
2. Определите бизнес-правила, основанные на описании операций.
3. Определите основные сущности и отношения из бизнес-правил.
4. Перевести лица/отношения к EER модели
5. Проверить именования
6. Карта ERR модель логической модели (стр 400) *
7. Нормализовать логическая модель (стр 179)
8. Улучшить дизайн DB (стр 187)
9. Validate Логическая модель Ограничения целостности (стр 402) (например, длина и т.д.)
10. Проверка логической модели от требований пользователя
11. Перевести таблицы в MYSQL код (в workbench переведите EER в файл SQL с помощью функции экспорта, а затем на mySQL)

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

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

4. Если база данных является сложной можно разбить дизайн ERD в followig субшаги
я) Создание внешних моделей (стр 46)
б) Объединить внешние модели для формирования концептуальной модели (стр 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: Используйте сплошные линии для подключения Слабые сущности (Слабые сущности являются те, которые не могут существовать без родительского объекта и содержат родители ПК в своем ПК). Используйте пунктирные линии для подключения Сильных Entities (сильные сущности являются те, которые могут существовать независимо от любого другого лица)

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

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

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

1. Карты сильных субъект (субъекты, не нужно другие объекты существует)
2. Карты супертипа/подтипы отношение
3. Карты слабых Entities
4. Карта бинарных отношений
5. Карта отношений с более высокой степенью

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

8.

1. Уточнить Атрибут Атомарность - Это, как правило, хорошая практика, чтобы обратить внимание на требования атомарности. Атомный атрибут - это тот, который не может быть разделен на . Говорят, что такой атрибут проявляет атомарность. Улучшая степень атомарности, вы также получаете гибкость запросов.

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

3. Постарайтесь ответить на вопросы: «Кому разрешено использовать таблицы и какие части (-ы) таблицы (-ов) будут доступны для пользователей?» И Т.П.

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

Answer 2

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

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

EDIT:

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

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

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

Есть два способа моделирования, один реальный сценарий, а другая является реальной структурой БД, IE:

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

смотрят эту Graphic, только N: субъекты M отношения были создавать (когда вы видите 2 или более FK, это таблица, отношение)

Но помните, это только «правила», и вы можете разорвать его, если ваш дизайн для работы, безопасности и т. д.

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

EDIT 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

Answer 3

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

Answer 4

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