В преддверии старта очередного потока по курсу «Базы данных» подготовили небольшой авторский материал с важными советами по конструированию БД. Надеемся данный материал будет полезен для вас.
Базы данных повсюду: от простейших блогов и директорий до надежных информационных систем и крупных социальных сетей. Не настолько важно, простая или сложная база данных, насколько существенно спроектировать ее правильно. Когда база спроектирована бездумно и без четкого понимания цели, она не просто не эффективна, но и дальнейшая работа с базой будет реальным мучением, непроходимым лесом для пользователей. Вот несколько советов по конструированию базы данных, которые помогут создать полезный и простой в использовании продукт.
Сегодня такие методы разработки, как Scrum или RAD (быстрая разработка приложения), помогают ИТ-командам быстро разрабатывать базы данных. Однако, в погоне за временем очень велик соблазн погрузиться сразу в построение базы, смутно представляя, в чем же сама цель, какие должны быть конечные результаты.
Как будто команда нацелена на эффективную, скоростную работу, но это мираж. Чем дальше и быстрее погружаться вглубь проекта, тем больше потребуется времени, чтобы выявить и изменить ошибки в проекте базы.
Поэтому первое, что нужно решить — это определить цель для вашей базы данных. Для какого типа приложения разрабатывается база? Пользователь будет лишь работать с записями и нужно уделить внимание транзакциям или его больше интересует аналитика данных? Где база должна быть развернута? Будет ли она отслеживать поведение клиентов или же просто управлять отношениями между ними?
Чем раньше команда проектирования ответит на эти вопросы, тем мягче, плавнее пройдет процесс проектирования базы данных.
Планируйте наперед. Мысли о том, что в будущем будет делать сайт или система, для которых проектируется база данных. Важно выходить за рамки простых требований технического задания. Только пожалуйста, не начинайте размышлять сразу обо всех возможных типах данных, которые когда-либо будет хранить пользователь. Лучше подумайте о том, смогут ли пользователи писать посты, загружать документы или фотографии или обмениваться сообщениями. Если это так, то в базе нужно выделить место под них.
Работайте с командой, департаментом или организацией, для которых в будущем будет поддерживаться проектируемая база. Общайтесь с людьми разных уровней, от специалистов по работе с клиентами до глав отделов. Так с помощью обратной связи вы получите четкое представление о требованиях компании.
Неизбежно потребности пользователей в рамках даже одного департамента будут конфликтовать. Если вы столкнетесь с этим, не бойтесь опереться на собственный опыт и найти компромисс, который устроит все стороны и будет удовлетворять конечной цели БД. Будьте уверенны: в будущем вам прилетит +100500 в карму и гора печенек.
Есть несколько ключевых моментов, на которые стоит обратить внимание при моделировании данных. Как мы уже ранее говорили, от назначения базы данных зависит, какие методы использовать при моделировании. Если мы проектируем базу данных для оперативной обработки записей (OLTP), иными словами для их создания, редактирования и удаления, то используем моделирование транзакций. Если же база данных должна быть реляционной, то лучше всего применять многомерное моделирование.
Во время моделирования строятся концептуальные (CDM), физические (PDM) и логические (LDM) модели данных.
Концептуальные модели описывают сущности и типы данных, которые они включают, а также отношения между ними. Делите ваши данные на логические куски — так намного проще жить.
Главное — мера, не переусердствуйте.
Если сущность очень сложно классифицировать одним словом или фразой, то пришло время использовать подтипы (дочерние сущности).
Если же сущность ведет собственную жизнь, имеет атрибуты, которые описывают ее поведение и ее вид, а также отношения с другими объектами, то смело можно использовать не только подтип, но и супертип ( родительская сущность).
Если пренебречь этим правилом, другие разработчики запутаются в вашей модели и не до конца будут понимать данные и правила, как их собирать.
Реализуются концептуальные модели с помощью логических. Эти модели словно дорожная карта для проектирования физической базы данных. В логической модели выделяются сущности бизнес-данных, определяются типы данных, статус ключа правила, которые регулируют отношения между данными.
Затем Логическая модель данных сопоставляется с выбранной заранее платформой СУБД (системы управления базами данных) и получается Физическая модель. Она описывает способ физического хранения данных.
Применение неправильного типа данных может привести к менее точным данным, трудностям в объединении таблиц, синхронизации атрибутов и к раздуванию размеров файлов.
Чтобы гарантировать целостность информации, атрибут должен содержать только приемлемые для него типы данных. Если в базу данных вносится возраст, то убедитесь, что в колонке хранятся целые числа из максимум 3 цифр.
Создавайте минимум пустых столбцов со значением NULL. Если вы создаете все столбцы как NULL, это грубая ошибка. Если же вам нужен пустой столбец для исполнения конкретной бизнес-функции, когда данные неизвестны или еще не имеют смысла, то смело создавайте. Ведь мы же не можем заранее заполнить столбцы “Дата смерти” или “Дата увольнения”, мы же не предсказатели тыкать пальцем в небо :-).
Большинство софта для моделирования (ER/Studio, MySQL Workbench, SQL DBM, gliffy
Когда вы решаете, какой столбец в таблице выбрать в качестве ключа, всегда обращайте внимание, какие поля может редактировать пользователь. Никогда не выбирайте их в качестве ключа — плохая идея. Произойти может все что угодно, а вы должны гарантировать уникальность.
Лучше всего использовать естественный, или бизнес, ключ (natural key). Он имеет смысловое значение, так вы избежите дублирования в базе данных.
Если только бизнес-ключ не уникален (имя, фамилия, должность) и повторяется в разных строках таблицы или он должен изменяться, то первичным ключом стоит назначить сгенерированный искусственный, суррогатный ключ (artificial key).
Чтобы эффективно организовать данные в БД, необходимо следовать набору рекомендаций и нормализовать базу данных. Существует пять нормальных форм, которым нужно следовать.
С помощью нормализации вы избежите избыточности и обеспечите целостность данных, использующихся в приложении или на сайте.
Как всегда, всего должно быть в меру, даже нормализации. Если в БД слишком много таблиц с одинаковыми уникальными ключами, то вы увлеклись и чрезмерно нормализовали базу данных. Излишняя нормализация негативно влияет на производительность базы данных.
Тестовый план и надлежащее тестирование должны быть частью проектирования базы данных.
Лучше всего тестировать базу данных путем Continuous Integration (непрерывной интеграции). Моделируйте сценарий “Один день из жизни базы данных” и проверяйте, все ли граничные случаи обрабатываются, какие взаимодействия пользователей вероятны. Чем раньше вы найдете баги, тем больше сэкономите и времени, и денег.
Это всего лишь семь советов, с помощью которых вы можете спроектировать отличную базу данных по производительности и эффективности. Если будете следовать им, вы избежите большинства головных болей в будущем. Эти советы — всего лишь верхушка айсберга в моделировании базы данных. Существует огромное число лайфхаков. Какими пользуетесь вы?
Базы данных повсюду: от простейших блогов и директорий до надежных информационных систем и крупных социальных сетей. Не настолько важно, простая или сложная база данных, насколько существенно спроектировать ее правильно. Когда база спроектирована бездумно и без четкого понимания цели, она не просто не эффективна, но и дальнейшая работа с базой будет реальным мучением, непроходимым лесом для пользователей. Вот несколько советов по конструированию базы данных, которые помогут создать полезный и простой в использовании продукт.
1. Определите, для чего таблица и какова ее структура
Сегодня такие методы разработки, как Scrum или RAD (быстрая разработка приложения), помогают ИТ-командам быстро разрабатывать базы данных. Однако, в погоне за временем очень велик соблазн погрузиться сразу в построение базы, смутно представляя, в чем же сама цель, какие должны быть конечные результаты.
Как будто команда нацелена на эффективную, скоростную работу, но это мираж. Чем дальше и быстрее погружаться вглубь проекта, тем больше потребуется времени, чтобы выявить и изменить ошибки в проекте базы.
Поэтому первое, что нужно решить — это определить цель для вашей базы данных. Для какого типа приложения разрабатывается база? Пользователь будет лишь работать с записями и нужно уделить внимание транзакциям или его больше интересует аналитика данных? Где база должна быть развернута? Будет ли она отслеживать поведение клиентов или же просто управлять отношениями между ними?
Чем раньше команда проектирования ответит на эти вопросы, тем мягче, плавнее пройдет процесс проектирования базы данных.
2. Какие данные выбрать для хранения?
Планируйте наперед. Мысли о том, что в будущем будет делать сайт или система, для которых проектируется база данных. Важно выходить за рамки простых требований технического задания. Только пожалуйста, не начинайте размышлять сразу обо всех возможных типах данных, которые когда-либо будет хранить пользователь. Лучше подумайте о том, смогут ли пользователи писать посты, загружать документы или фотографии или обмениваться сообщениями. Если это так, то в базе нужно выделить место под них.
Работайте с командой, департаментом или организацией, для которых в будущем будет поддерживаться проектируемая база. Общайтесь с людьми разных уровней, от специалистов по работе с клиентами до глав отделов. Так с помощью обратной связи вы получите четкое представление о требованиях компании.
Неизбежно потребности пользователей в рамках даже одного департамента будут конфликтовать. Если вы столкнетесь с этим, не бойтесь опереться на собственный опыт и найти компромисс, который устроит все стороны и будет удовлетворять конечной цели БД. Будьте уверенны: в будущем вам прилетит +100500 в карму и гора печенек.
3. Моделируйте данные с осторожностью
Есть несколько ключевых моментов, на которые стоит обратить внимание при моделировании данных. Как мы уже ранее говорили, от назначения базы данных зависит, какие методы использовать при моделировании. Если мы проектируем базу данных для оперативной обработки записей (OLTP), иными словами для их создания, редактирования и удаления, то используем моделирование транзакций. Если же база данных должна быть реляционной, то лучше всего применять многомерное моделирование.
Во время моделирования строятся концептуальные (CDM), физические (PDM) и логические (LDM) модели данных.
Концептуальные модели описывают сущности и типы данных, которые они включают, а также отношения между ними. Делите ваши данные на логические куски — так намного проще жить.
Главное — мера, не переусердствуйте.
Если сущность очень сложно классифицировать одним словом или фразой, то пришло время использовать подтипы (дочерние сущности).
Если же сущность ведет собственную жизнь, имеет атрибуты, которые описывают ее поведение и ее вид, а также отношения с другими объектами, то смело можно использовать не только подтип, но и супертип ( родительская сущность).
Если пренебречь этим правилом, другие разработчики запутаются в вашей модели и не до конца будут понимать данные и правила, как их собирать.
Реализуются концептуальные модели с помощью логических. Эти модели словно дорожная карта для проектирования физической базы данных. В логической модели выделяются сущности бизнес-данных, определяются типы данных, статус ключа правила, которые регулируют отношения между данными.
Затем Логическая модель данных сопоставляется с выбранной заранее платформой СУБД (системы управления базами данных) и получается Физическая модель. Она описывает способ физического хранения данных.
4. Используйте подходящие типы данных
Применение неправильного типа данных может привести к менее точным данным, трудностям в объединении таблиц, синхронизации атрибутов и к раздуванию размеров файлов.
Чтобы гарантировать целостность информации, атрибут должен содержать только приемлемые для него типы данных. Если в базу данных вносится возраст, то убедитесь, что в колонке хранятся целые числа из максимум 3 цифр.
Создавайте минимум пустых столбцов со значением NULL. Если вы создаете все столбцы как NULL, это грубая ошибка. Если же вам нужен пустой столбец для исполнения конкретной бизнес-функции, когда данные неизвестны или еще не имеют смысла, то смело создавайте. Ведь мы же не можем заранее заполнить столбцы “Дата смерти” или “Дата увольнения”, мы же не предсказатели тыкать пальцем в небо :-).
Большинство софта для моделирования (ER/Studio, MySQL Workbench, SQL DBM, gliffy
.com) данных позволяет создавать прототипы областей данных. Так гарантируется не только правильный тип данных, логика приложения и хорошая производительность, но также и обязательное задание значения. 5. Предпочитайте естественное
Когда вы решаете, какой столбец в таблице выбрать в качестве ключа, всегда обращайте внимание, какие поля может редактировать пользователь. Никогда не выбирайте их в качестве ключа — плохая идея. Произойти может все что угодно, а вы должны гарантировать уникальность.
Лучше всего использовать естественный, или бизнес, ключ (natural key). Он имеет смысловое значение, так вы избежите дублирования в базе данных.
Если только бизнес-ключ не уникален (имя, фамилия, должность) и повторяется в разных строках таблицы или он должен изменяться, то первичным ключом стоит назначить сгенерированный искусственный, суррогатный ключ (artificial key).
6. Нормализуйте в меру
Чтобы эффективно организовать данные в БД, необходимо следовать набору рекомендаций и нормализовать базу данных. Существует пять нормальных форм, которым нужно следовать.
С помощью нормализации вы избежите избыточности и обеспечите целостность данных, использующихся в приложении или на сайте.
Как всегда, всего должно быть в меру, даже нормализации. Если в БД слишком много таблиц с одинаковыми уникальными ключами, то вы увлеклись и чрезмерно нормализовали базу данных. Излишняя нормализация негативно влияет на производительность базы данных.
7. Тестируйте пораньше, тестируйте почаще
Тестовый план и надлежащее тестирование должны быть частью проектирования базы данных.
Лучше всего тестировать базу данных путем Continuous Integration (непрерывной интеграции). Моделируйте сценарий “Один день из жизни базы данных” и проверяйте, все ли граничные случаи обрабатываются, какие взаимодействия пользователей вероятны. Чем раньше вы найдете баги, тем больше сэкономите и времени, и денег.
Это всего лишь семь советов, с помощью которых вы можете спроектировать отличную базу данных по производительности и эффективности. Если будете следовать им, вы избежите большинства головных болей в будущем. Эти советы — всего лишь верхушка айсберга в моделировании базы данных. Существует огромное число лайфхаков. Какими пользуетесь вы?
