Интервьюер Tmall: Как спроектировать базу данных? я тупой

Java база данных

Есть чувства, есть галантерейные товары, поиск в WeChat【Третий принц Ао Бин] Обратите внимание на этого другого программиста.

эта статьяGitHub github.com/JavaFamilyВключено, и есть полные тестовые площадки, материалы и мой цикл статей для интервью с производителями первой линии.

предисловие

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

В процессе разработки программного обеспечения проектирование базы данных очень важно: необходимо абстрагировать диаграмму E-R, разработать логическую структуру, выбрать базу данных, физический дизайн, реализовать, эксплуатировать и поддерживать в соответствии с анализом спроса. Давайте поговорим об этих вещах, связанных с проектированием баз данных в те годы.

разработка программного обеспечения

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

Основные этапы проектирования базы данных

этап анализа требований

Чтобы выполнить проектирование базы данных, мы должны сначала понять потребности пользователей и принять участие в анализе спроса пользователей.SA (структурированный анализ: метод структурированного анализа) обычно используется в анализе спроса.Метод разработки программного обеспечения, который подчеркивает структурную рациональность метода разработки и структурная рациональность разрабатываемого программного обеспечения, представляет собой наследование и развитие метода жизненного цикла, а также сочетание метода жизненного цикла и идеи структурного программирования.

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

  1. Сначала нарисуйте входные и выходные данные системы, сначала нарисуйте диаграмму потока данных верхнего уровня (DFD: диаграмма потока данных), диаграмма потока данных верхнего уровня содержит только одну обработку для представления разрабатываемой системы, а затем рассмотрите, какие входные данные и потоки выходных данных, которые есть в системе.
  2. Нарисуйте внутреннюю часть системы, то есть нарисуйте диаграмму нижнего слоя потока данных.

Ниже приведен DFD торговой системы.Сначала необходимо нарисовать схему потока данных верхнего уровня, которая в основном включает взаимодействие между подмодулями системы, а затем выполнить дальнейшую декомпозицию подмодулей.

Стадия разработки концепции

Концептуальное проектирование является ключом ко всему проектированию базы данных, оно заключается в синтезе, архивировании и абстрагировании результатов фазы анализа требований в независимую и конкретную модель СУБД, независимую от конкретного продукта РСУБД.

В реальной разработке для представления обычно используется диаграмма ER (Entity-Relationship: Entity Relationship), а широко используемый инструмент PowerDesigner может реализовать CDM (концептуальная модель данных) -> LDM (логическая модель данных) -> PDM (физическая модель данных) -> Автоматическое преобразование базы данных, этот процесс называетсяФорвард инжиниринг, если есть скрипт построения базы данных, вы также можете сгенерировать CDM через инструмент PowerDesigner, то есть Database->PDM->LDM->CDM, называемыйРазобрать механизм с целью понять, как это работает.

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

Например, сейчас я отвечаю за разработку торговой системы, в основном за счет модулей ордеров и цен, которые передаются разным разработчикам для проектирования и разработки.

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

существительное глагол прилагательное анализ

Разработайте, как спроектировать диаграмму ER в соответствии с анализом спроса, завершите детальный проект модуля, предоставьте документ интерфейса, и, самое главное, диаграмму ER абстрактного этапа CDM анализа спроса Эффективный методсуществительное глагол прилагательное анализ, этот метод анализа подробно объясняется ниже.

Приведу пример.Теперь пусть я буду отвечать за разработку порядка торговой системы.Я видел предложение в документе анализа спроса.Эффективное управление заказами, процесс анализа выглядит следующим образом:

название: Заказ, заказ является Сущностью, а также может быть разделен на несколько Сущностей, абстрагируя Атрибут каждой Сущности (может быть из-за неясных требований на ранней стадии, можно только подтвердить содержание), Сущность преобразуется в базу данных с помощью передовой разработки PowerDesigner В таблице данных атрибут является полем таблицы, таблица данных сопоставляется с Java через ORM как класс, а поле является частным атрибутом.

глагол: Управление, то есть добавлять, удалять, изменять и проверять CRUD-операции по ордерам.

имя прилагательное: Эффективно, во-первых, подумайте о создании подходящего индекса в таблице заказов, а во-вторых, в соответствии с развитием бизнеса, если таблица заказов слишком велика, это повлияет на производительность записи, будь то разделение чтения и записи, и операции с подбазой данных и подтаблицей.

Три парадигмы проектирования баз данных

Первая нормальная форма 1NF: гарантирует, что каждое поле остается атомарным и неделимым.

Для пользователей таблицы пользователей существует имя пользователя (обычно состоящее из first_name и last_name), если вы используете составной тип данных, такой как Oracle, это нарушает 1NF.

Очевидно, что поле user_name пользователей имеет пользовательский тип и является разложимым, что нарушает 1NF.

Вторая нормальная форма 2NF: Убедитесь, что поле полностью зависит от первичного ключа.

В таблице может храниться только один тип данных, а несколько типов данных не могут храниться в одной таблице. Если в таблице хранится и информация о пользователе, и информация о товаре, и информация о заказе, это нарушает 2NF. Таблица товаров и таблица заказов должны быть разделены на три таблицы, чтобы гарантировать, что поля принадлежат таблице.

Третья нормальная форма 3NF: 2NF должен быть выполнен, и каждый атрибут в сущности напрямую связан с первичным ключом и не может быть связан косвенно.

Это нетрудно понять.Для заказов таблицы заказов необходимо хранить user_id пользователей таблицы пользователей и уточнять, какой пользователь разместил заказ.В некоторых бизнес-сценариях имя пользователя user_name таблицы пользователей необходимо получить, чтобы уменьшить количество заказов и таблицы пользователей.Ассоциативный запрос, избыточное user_name в таблице заказов, этот дизайн нарушает 3NF, уменьшает избыточность данных и может соединяться между таблицами через первичные и внешние ключи.

Должен ли я использовать внешний ключ или нет?

Назначение внешних ключей — обеспечить целостность и непротиворечивость данных и избежать создания грязных данных.Каковы недостатки установки внешних ключей?

  1. Влияет на производительность записи: Для вставки необходимо каждый раз судить, существует ли столбец внешнего ключа подчиненной таблицы в основной таблице (например, каждый раз, когда вставляется таблица заказов, необходимо судить, существует ли user_id в пользователях) , что снизит производительность записи базы данных. , Для базы данных не подходит то, что MySQL имеет возможность только вывода и записи мастера. Также разумно, что спецификация разработки MySQL не позволяет использовать внешние ключи.

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

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

этап логического проектирования

Этап логического проектирования заключается в преобразовании концептуальной модели данных в модель данных, поддерживаемую конкретной СУБД, которая будет оптимизирована. Хотя LDM не зависит от СУБД, он может выполнять работу по проектированию внешних ключей, индексов, представлений и других объектов.

На данном этапе между ER-диаграммами каждого подмодуля в основном существует три типа конфликтов: конфликты атрибутов, конфликты имен и структурные конфликты.В то же время преобразование ER-диаграмм в реляционные модели требует решения, как преобразовать сущность и отношения между сущностями в отношениях.Режим, определить атрибуты и коды этих режимов отношений, в фактической разработке этап логического проектирования не требуется, а некоторые напрямую из CDM в PDM.

Выбор базы данных

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

Например: для бизнес-сценария транзакций DAU 1000W TPS 3W, если MySQL используется в качестве хранилища, мы знаем, что узкое место записи в MySQL и проблемы с производительностью, вызванные быстрым ростом данных таблиц, связанных с заказами, не подходят для этого типа. Для сценариев с высокой параллельной записью вы можете рассмотреть возможность использования распределенного MySQL, такого как распространенные DRDS, TiDB и OceanBase. Он может не только устранить узкое место написания в MySQL, но и решить проблему подбазы данных и подтаблицы, вызванную большим объемом данных в одной таблице.

Точно так же для видеосистем, таких как Youku и iQiyi, не подходит использование MySQL для хранения, и для хранения следует использовать кластер MongoDB; для JD.com поисковая служба Taobao использует обработку кластера базы данных ElastSearch для большей эффективности.

этап физического проектирования

После завершения этапа логического проектирования и выбора базы данных PDM может быть создан с помощью LDM.На этапе физического проектирования необходимо разработать объекты, связанные с СУБД, такие как проектирование хранимых процедур, триггеров, определяемых пользователем функций. и табличные пространства.

Этап реализации базы данных

Например, выбрана база данных MySQL.После создания сценария построения базы данных через PDM требуется нормативная проверка.После прохождения может быть создана структура таблицы.Нормативная проверка может использовать инструменты аудита SQL с открытым исходным кодом, такие как Yearning, Archery может устанавливать правила, после проверки он дает предложения по исправлению, которые могут помочь нам автоматически внедрить SQL Review. Yearning разрабатывается на ходу, в настоящее время поддерживает только базу данных MySQL, Archery может поддерживать различные базы данных. Ниже приведен пример обнаружения DDL-тикета для автоматизированной платформы аудита SQL Yearning.

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

Фаза обслуживания базы данных

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

Суммировать

В реальной разработке этап проектирования базы данных очень важен.Обычно он разрабатывается сам по себе для анализа в соответствии с потребностями бизнес-модулей, извлечения его в диаграмму ER в CDM, преобразования его в LDM, после выбора базы данных и создания PDM, наконец, сгенерируйте таблицу базы данных, а затем для того, чтобы начать кодирование, тестирование, публикацию и итерацию версии, чтобы обеспечить безопасность, стабильность и эффективность онлайн-бизнеса, необходимо провести усовершенствованное управление и обслуживание базы данных.

Нетрудно обнаружить, что в основе проектирования баз данных лежит понимание анализа спроса и извлечение диаграмм ER.Это требует глубоких, немедленных и абстрактных возможностей для отрасли и связанных с ней предприятий.Если у вас есть какие-либо открытия, фронт рекрутинга Инженеры Java Дополнительные бизнес-атрибуты, такие как инженеры Java домена пользователя и инженеры Java домена оплаты, в основном отражаются в абстракции анализа спроса и возможности проектирования моделей данных.Очень необходимо участвовать в обсуждениях бизнес-потребностей в процессе разработки. Это все, о чем я говорил сегодня, я надеюсь, что это будет полезно для всех.

Я Ао Бин,Чем больше вы знаете, тем больше вы не знаете, спасибо за ваши таланты:как,собиратьиКомментарий, увидимся в следующий раз!


Статья постоянно обновляется, вы можете искать в WeChat "Третий принц Ао Бин"Прочтите это в первый раз, ответьте [материал] Подготовленные мной материалы интервью и шаблоны резюме крупных заводов первой линии, эта статьяGitHub github.com/JavaFamilyОн был включен, и есть полные тестовые сайты для интервью с крупными заводами.Добро пожаловать в Star.