Базы данных используются повсюду, включая большую часть проектов в мире веб-разработки. Всё, начиная от простейших блогов и каталогов, до серьезных социальных веб-проектов. Независимо от сложности сайта и соответствующей базы данных, каждый из них требует тщательного проектирования, чтобы работать эффективно, а также надежно.
В этой статье мы рассмотрим основы разработки хорошего плана базы данных, независимо от ее окончательного предназначения. Для всех вариантов структуры баз данных есть набор стандартных правил и лучших практик, которыми следует пользоваться. Они будут способствовать базе данных оставаться организованной и сделает ее взаимодействие с сайтом более разумным и эффективным способом.
Первый метод, используемый при планировании, это обычный мозговой штурм, делая записи на бумаге или как-то еще, в зависимости от того, что требуется хранить в базе данных, и что будет требоваться сайту. Старайтесь не думать об конкретных полях, таблицах, которые будут использоваться в конкретном случае — все специфичные моменты будут рассмотрены вами позже. Ваша цель на данном этапе состоит в том, чтобы получить общую и полную картину структуры базы данных, которую потом будете уточнять и делать более подробной. Зачастую в дальнейшем может быть более трудным добавить какие-то элементы в ваш план, нежели на первоначальном этапе.
Отстранитесь от базы данных. Попытайтесь подумать, что будет требоваться от сайта? Например, если требуется сделать сайт, объединяющий людей, вы, возможно, сразу начнете думать о данных, которые будут хранить пользователи. Забудьте, отложите это на потом. Лучше запишите, что пользователи и информация о них должна храниться в базе данных. А что еще? Что пользователи будут делать на вашем сайте? Будут ли они публиковать записи, загружать файлы, фотографии, писать друг другу сообщения? Следовательно, база данных должна хранить всю эту информацию: записи, файлы, фотографии, сообщения и т. д.
Как будут взаимодействовать пользователи с вашим сайтом? Будет ли у них необходимость в поиске, например, их любимых рецептов, иметь доступ к записям, доступным конкретному сообществу, искать продукты или смотреть список недавно просмотренных и купленных продуктов? В базе данных должна быть предусмотрена возможность хранить рецепты, «закрытые» записи, доступные определенному кругу пользователей, информацию о продуктах, а также возможность связи определенного продукта и пользователя.
Следующий этап заключается в том, чтобы определить, какие именно таблицы и поля потребуются в базе данных. Это ядро разработки и самая сложная её часть. Использование правильных методов связки таблиц, определение структуры данных в каждой таблице, выявление необходимости разброса этих данных по разным таблицам, — все эти проблемы всплывают при непосредственном проектировании базы данных. Теперь вам необходимо определить список очевидно необходимых таблиц и полей, будьте как можно более конкретным. В ходе этого процесса, какие-то элементы могут быть перестроены либо реорганизованы в целях повышения эффективности и безопасности базы данных.
Теперь, когда вы знаете, что сайт должен будет делать, самое время определить, какую конкретно информацию нужно будет хранить. Очень уместным здесь окажется инструмент для проектирования баз данных, особенно имеющий возможность создавать визуальные модели базы данных, например, MySQL Workbench либо DBDesigner4. Gliffy является отличным бесплатным он-лайн инструментом для создания различных блок-схем и моделей баз данных.
Есть также более известный, качественный, на мой взгляд, инструмент — Microsoft Visio (только под Windows, цена $249.99). Но не пугайтесь, есть более дешевые альтернативы, многие из которых являются open-source проектами, в том числе два, упомянутых выше.
Ознакомьтесь с общими графическими обозначениями и стандартными визуальными элементами, необходимым для создания модели базы данных, и начните предварительное планирование с помощью блок-схем и диаграмм. Это позволит избежать логических ошибок, прежде чем будет создана уже какая-нибудь конкретная база данных.
Большинство баз данных являются реляционными базами данных. Это означает, что таблицы в базе данных связаны между собой каким-либо образом. Например, если существует «пользователь» на сайте интертнет-магазина, то он наверняка может быть связан с определенными продуктами, на основании информации об их заказах либо указании желаемых продуктах. Для базы данных блога авторы должны быть как-то связаны с записями, которые они написали, а авторизованные пользователи должны быть связаны с оставленными ими комментариями.
С помощью определенных методов реляционных баз данных мы можем хранить огромное количество информации в организованном виде в отдельных таблицах: одна для пользователей, одна для записей, одна для комментариев, для продуктов и т.д. Теперь мы можем связать данные в разных таблицах, использую уникальные ключи.
Любая запись в каждой таблице должна иметь уникальный ключ. Это типа «номера социального страхования» или «штрих-кода» для записи. Он является уникальным для каждой записи. И никакая другая записи не может иметь такой же идентификатор в той же таблице. Наличие уникальных имен или названий продуктов в базе данных не достаточно. Гораздо более эффективным является использование уникальных первичных ключей. Даже несколько уникальных полей в базе данных не защищают ее от возможности дублирования данных, что впоследствии может негативно сказаться на работе сайта.
Для связи двух таблиц мы используем внешний ключ, который является всего лишь идентификатором, ссылающимся на уникальный ключ в другой таблице, обычно это первичный ключ. В примере ниже мы видим, что первая таблица содержит информацию о трех авторах с уникальным идентификатором (id). Во второй таблице мы связываем каждую запись о статье с автором через этот идентификатор. Теперь мы можем найти автора первой статьи, и наоборот, видеть, что Том написал две статьи, Мэри — одну, а Джейн еще ни одной.
Это простая модель отношения вида один-к-одному. Существую также модели один-ко-многим и многие-ко-многим.
Что касается полей, также важно знать, когда группировать определенную часть данных, а когда нет. Хороший способ определить, какая информация должна быть в одном поле или наоборот, подумать, будет ли необходимость изменять какую-либо её часть? Например, нужно ли хранить адрес, разбив его на составляющие: 1) улица, 2) город, 3) штат, 4) почтовый код, 5) страна?
Это неотъемлемая часть функционала сайта (возможно, пользователи или администраторы захотят искать других пользователей по адресу или штату), или просто увеличение места, занимаемого базой данных на диске? Если это не столь важно, зачем тогда нагружать базу данных на изменение 5 полей, когда можно обновить всего лишь одно строковое поле. Более удобным может быть вариант получения этих данных из HTML-формы, где поля разделены, а уже перед добавлением адреса в базу данных объединять значения из соответствующих полей в одну строку.
Это только один пример, но всегда имейте представление о наиболее эффективные способы организации полей таблицы, когда объединять их, когда содержать отдельно, ради поддержания функциональности сайта.
Нормализация представляет набор руководящих принципов, созданных для организации более эффективного хранения информации. Мы уже упоминали о некоторых важных основных практиках, которые входят в наиболее популярные нормальные формы. Есть пять нормальных форм. Было бы полезным ознакомиться с этими нормальными формами и разрабатывать базы данных в соответствии с их требованиями.
Нормализация базы данных большая тема, но уже понимание ее основ может вам чрезвычайно помочь. Чтобы иметь общее представление о каждой нормальной форме и нормализации в целом, не забудьте взглянуть на Основы нормализации баз данных.
Проектирование баз данных — обширная тема, но от вас не потребуется многого, чтобы изучить основы и иметь представление о правильной структуре баз данных. Может быть, наиболее важным этапом проектирования базы данных является само его начало и мозговой штурм. Это то, что позволяет любому разработчику получить всю необходимую информацию заранее и реализовывать задуманное по мере необходимости. Только имея всю необходимую информацию для проектирования, можно создать эффективную базу данных с правильно связанными таблицами.
Любая база данных должна быть эффективной и масштабируемой. Данные постоянно редактируются, добавляются, удаляются, поэтому важным будет содержать базу данных организованной таким образом, чтобы поддерживать этот постоянно изменяющийся набор данных. Убедитесь, чтобы в создаваемой базе данных удалялась только та информация, которая должна, не дублировались бы записи и можно было бы ссылаться на другие данных легко и просто.
В этой статье мы рассмотрим основы разработки хорошего плана базы данных, независимо от ее окончательного предназначения. Для всех вариантов структуры баз данных есть набор стандартных правил и лучших практик, которыми следует пользоваться. Они будут способствовать базе данных оставаться организованной и сделает ее взаимодействие с сайтом более разумным и эффективным способом.
Какой функционал требуется от базы данных
Первый метод, используемый при планировании, это обычный мозговой штурм, делая записи на бумаге или как-то еще, в зависимости от того, что требуется хранить в базе данных, и что будет требоваться сайту. Старайтесь не думать об конкретных полях, таблицах, которые будут использоваться в конкретном случае — все специфичные моменты будут рассмотрены вами позже. Ваша цель на данном этапе состоит в том, чтобы получить общую и полную картину структуры базы данных, которую потом будете уточнять и делать более подробной. Зачастую в дальнейшем может быть более трудным добавить какие-то элементы в ваш план, нежели на первоначальном этапе.
Фото: binaryape
Отстранитесь от базы данных. Попытайтесь подумать, что будет требоваться от сайта? Например, если требуется сделать сайт, объединяющий людей, вы, возможно, сразу начнете думать о данных, которые будут хранить пользователи. Забудьте, отложите это на потом. Лучше запишите, что пользователи и информация о них должна храниться в базе данных. А что еще? Что пользователи будут делать на вашем сайте? Будут ли они публиковать записи, загружать файлы, фотографии, писать друг другу сообщения? Следовательно, база данных должна хранить всю эту информацию: записи, файлы, фотографии, сообщения и т. д.
Как будут взаимодействовать пользователи с вашим сайтом? Будет ли у них необходимость в поиске, например, их любимых рецептов, иметь доступ к записям, доступным конкретному сообществу, искать продукты или смотреть список недавно просмотренных и купленных продуктов? В базе данных должна быть предусмотрена возможность хранить рецепты, «закрытые» записи, доступные определенному кругу пользователей, информацию о продуктах, а также возможность связи определенного продукта и пользователя.
Определение необходимых таблиц и полей
Следующий этап заключается в том, чтобы определить, какие именно таблицы и поля потребуются в базе данных. Это ядро разработки и самая сложная её часть. Использование правильных методов связки таблиц, определение структуры данных в каждой таблице, выявление необходимости разброса этих данных по разным таблицам, — все эти проблемы всплывают при непосредственном проектировании базы данных. Теперь вам необходимо определить список очевидно необходимых таблиц и полей, будьте как можно более конкретным. В ходе этого процесса, какие-то элементы могут быть перестроены либо реорганизованы в целях повышения эффективности и безопасности базы данных.
Используйте инструмент моделирования данных
Теперь, когда вы знаете, что сайт должен будет делать, самое время определить, какую конкретно информацию нужно будет хранить. Очень уместным здесь окажется инструмент для проектирования баз данных, особенно имеющий возможность создавать визуальные модели базы данных, например, MySQL Workbench либо DBDesigner4. Gliffy является отличным бесплатным он-лайн инструментом для создания различных блок-схем и моделей баз данных.
Есть также более известный, качественный, на мой взгляд, инструмент — Microsoft Visio (только под Windows, цена $249.99). Но не пугайтесь, есть более дешевые альтернативы, многие из которых являются open-source проектами, в том числе два, упомянутых выше.
Ознакомьтесь с общими графическими обозначениями и стандартными визуальными элементами, необходимым для создания модели базы данных, и начните предварительное планирование с помощью блок-схем и диаграмм. Это позволит избежать логических ошибок, прежде чем будет создана уже какая-нибудь конкретная база данных.
Реляционные базы данных
Большинство баз данных являются реляционными базами данных. Это означает, что таблицы в базе данных связаны между собой каким-либо образом. Например, если существует «пользователь» на сайте интертнет-магазина, то он наверняка может быть связан с определенными продуктами, на основании информации об их заказах либо указании желаемых продуктах. Для базы данных блога авторы должны быть как-то связаны с записями, которые они написали, а авторизованные пользователи должны быть связаны с оставленными ими комментариями.
С помощью определенных методов реляционных баз данных мы можем хранить огромное количество информации в организованном виде в отдельных таблицах: одна для пользователей, одна для записей, одна для комментариев, для продуктов и т.д. Теперь мы можем связать данные в разных таблицах, использую уникальные ключи.
Любая запись в каждой таблице должна иметь уникальный ключ. Это типа «номера социального страхования» или «штрих-кода» для записи. Он является уникальным для каждой записи. И никакая другая записи не может иметь такой же идентификатор в той же таблице. Наличие уникальных имен или названий продуктов в базе данных не достаточно. Гораздо более эффективным является использование уникальных первичных ключей. Даже несколько уникальных полей в базе данных не защищают ее от возможности дублирования данных, что впоследствии может негативно сказаться на работе сайта.
Для связи двух таблиц мы используем внешний ключ, который является всего лишь идентификатором, ссылающимся на уникальный ключ в другой таблице, обычно это первичный ключ. В примере ниже мы видим, что первая таблица содержит информацию о трех авторах с уникальным идентификатором (id). Во второй таблице мы связываем каждую запись о статье с автором через этот идентификатор. Теперь мы можем найти автора первой статьи, и наоборот, видеть, что Том написал две статьи, Мэри — одну, а Джейн еще ни одной.
Это простая модель отношения вида один-к-одному. Существую также модели один-ко-многим и многие-ко-многим.
Группировка и разделение данных
Что касается полей, также важно знать, когда группировать определенную часть данных, а когда нет. Хороший способ определить, какая информация должна быть в одном поле или наоборот, подумать, будет ли необходимость изменять какую-либо её часть? Например, нужно ли хранить адрес, разбив его на составляющие: 1) улица, 2) город, 3) штат, 4) почтовый код, 5) страна?
Это неотъемлемая часть функционала сайта (возможно, пользователи или администраторы захотят искать других пользователей по адресу или штату), или просто увеличение места, занимаемого базой данных на диске? Если это не столь важно, зачем тогда нагружать базу данных на изменение 5 полей, когда можно обновить всего лишь одно строковое поле. Более удобным может быть вариант получения этих данных из HTML-формы, где поля разделены, а уже перед добавлением адреса в базу данных объединять значения из соответствующих полей в одну строку.
Это только один пример, но всегда имейте представление о наиболее эффективные способы организации полей таблицы, когда объединять их, когда содержать отдельно, ради поддержания функциональности сайта.
Нормализация базы данных
Нормализация представляет набор руководящих принципов, созданных для организации более эффективного хранения информации. Мы уже упоминали о некоторых важных основных практиках, которые входят в наиболее популярные нормальные формы. Есть пять нормальных форм. Было бы полезным ознакомиться с этими нормальными формами и разрабатывать базы данных в соответствии с их требованиями.
Нормализация базы данных большая тема, но уже понимание ее основ может вам чрезвычайно помочь. Чтобы иметь общее представление о каждой нормальной форме и нормализации в целом, не забудьте взглянуть на Основы нормализации баз данных.
Заключение
Проектирование баз данных — обширная тема, но от вас не потребуется многого, чтобы изучить основы и иметь представление о правильной структуре баз данных. Может быть, наиболее важным этапом проектирования базы данных является само его начало и мозговой штурм. Это то, что позволяет любому разработчику получить всю необходимую информацию заранее и реализовывать задуманное по мере необходимости. Только имея всю необходимую информацию для проектирования, можно создать эффективную базу данных с правильно связанными таблицами.
Любая база данных должна быть эффективной и масштабируемой. Данные постоянно редактируются, добавляются, удаляются, поэтому важным будет содержать базу данных организованной таким образом, чтобы поддерживать этот постоянно изменяющийся набор данных. Убедитесь, чтобы в создаваемой базе данных удалялась только та информация, которая должна, не дублировались бы записи и можно было бы ссылаться на другие данных легко и просто.
Дополнительные ресурсы
- Руководство по проектированию баз данных
- 10 распространенных ошибок при проектировании баз данных
- Введение в проектирование баз данных
- Основы разработки баз данных
- 7 шагов к правильному проектированию баз данных
