Пред.ОглавлениеСлед.

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

Проектирование включает в себя следующие основные этапы.

• Определение требований к базе данных.

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

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

• Создание модели данных, соответствующей всем предъявленным требованиям. Для разработки модели данных на основе сформулированных требований можно использовать одну из двух противоположных стратегий.

• Проектирование «снизу вверх», от элемента к структуре: вначале определяется, какие именно атрибуты должны храниться в базе данных, затем группы атрибутов объединяются в объекты. Этот метод годится для небольших баз данных, в которых количество атрибутов невелико.

• Проектирование «сверху вниз» начинается с выделения высокоуровневых объектов и связей между ними, затем осуществляется декомпозиция объектов и последовательная детализация модели до уровня атрибутов. Для сложных баз данных с большим количеством атрибутов такой метод более эффективен, чем метод «снизу вверх».

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

• Для клиентов: идентификатор, имя (или название организации), номер контактного телефона, адрес, а также рейтинг, используемый для расчета скидки.

• Для товаров: идентификатор, наименование, описание, название склада, где хранится этот вид товара, и адрес склада.

• Для заказов: дату заказа, идентификатор заказанного товара, количество товаров этого наименования, общую стоимость заказа с учетом скидки, идентификатор клиента, сделавшего заказ, и адрес клиента, куда нужно доставить заказ (здесь мы предполагаем, что каждый заказ может включать только одно наименование товара).

• Нормализация.

Нормализация базы данных заключается в минимизации избыточности данных. Нормализация позволяет уменьшить объем БД и устранить потенциальную противоречивость данных (например, если в базе данных одна и та же информация дублируется в нескольких местах, то при ее обновлении есть риск появления разночтений).

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

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

Ответ на вопрос, является ли атрибут атомарным, зависит от функциональных требований к базе данных. Рассмотрим, например, столбец address (адрес) из таблицы Customers (Клиенты) (см. табл. 1.1). Если адрес клиента будет использоваться только целиком, то этот столбец является атомарным. Если же потребуется получать из базы отдельно название города, улицы и т. п., то для приведения таблицы Customers к первой нормальной форме столбец address следует разбить на столбцы city (город), street (улица), building (здание) и т. д.

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

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

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

…

Примечание

Атрибут A функционально зависит от группы атрибутов B, если значение атрибута A однозначно определяется набором значений группы атрибутов B, иными словами, в строках с одинаковым набором значений атрибутов группы B значение атрибута A также одинаково.

• Таблица находится в если она находится во второй нормальной форме и любой неключевой атрибут функционально зависит от первичного ключа.

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

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

Итак, мы разработали логическую структуру базы данных, и можно переходить к созданию базы данных в СУБД MySQL. Если программа MySQL еще не установлена на вашем компьютере, из следующего раздела вы узнаете, как это сделать.

Design

MySQL Workbench enables a DBA, developer, or data architect to visually design, model, generate, and manage databases. It includes everything a data modeler needs for creating complex ER models, forward and reverse engineering, and also delivers key features for performing difficult change management and documentation tasks that normally require much time and effort.
Learn More »

Develop

MySQL Workbench delivers visual tools for creating, executing, and optimizing SQL queries. The SQL Editor provides color syntax highlighting, auto-complete, reuse of SQL snippets, and execution history of SQL. The Database Connections Panel enables developers to easily manage standard database connections, including MySQL Fabric. The Object Browser provides instant access to database schema and objects.
Learn more »

Administer

MySQL Workbench provides a visual console to easily administer MySQL environments and gain better visibility into databases. Developers and DBAs can use the visual tools for configuring servers, administering users, performing backup and recovery, inspecting audit data, and viewing database health.
Learn more »

Visual Performance Dashboard

MySQL Workbench provides a suite of tools to improve the performance of MySQL applications. DBAs can quickly view key performance indicators using the Performance Dashboard. Performance Reports provide easy identification and access to IO hotspots, high cost SQL statements, and more.

1.3. Проектирование базы данных

Plus, with 1 click, developers can see where to optimize their query with the improved and easy to use Visual Explain Plan.
Learn More »

Database Migration

MySQL Workbench now provides a complete, easy to use solution for migrating Microsoft SQL Server, Microsoft Access, Sybase ASE, PostreSQL, and other RDBMS tables, objects and data to MySQL. Developers and DBAs can quickly and easily convert existing applications to run on MySQL both on Windows and other platforms. Migration also supports migrating from earlier versions of MySQL to the latest releases.
Learn more »