Разработка форм приложений и интерфейса

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

Концептуальная модель является моделью предметной области и включает описания объектов и их взаимосвязей, выявляемых в результате анализа данных. Используемым на этом этапе средством моделирования данных являются диаграммы «сущность-связь» (ERD). Они предназначены для разработки моделей данных и обеспечивают стандартный способ определения данных и отношений между ними. Фактически с помощью ERD осуществляется детализация хранилищ данных проектируемой системы, а также документируются сущности системы и способы их взаимодействия, включая идентификацию объектов, важных для предметной области (сущностей), свойств этих объектов (атрибутов) и их отношений с другими объектами (связей). Данная нотация была введена Ченом и получила дальнейшее развитие в работах Баркера.

Разработка ERD включает следующие основные этапы: идентификация сущностей, их атрибутов, а также первичных и альтернативных ключей; идентификация связей между сущностями и указание типов связей; нормализация сущностей и разрешение неспецифических отношений (отношений «многие-ко-многим»).

При построении диаграммы потоков данных были выявлены следующие хранилища данных:

• — лист-заявка;
• — заказ;
• — справочник продуктов;
• — клиент;
• — заявка;
• — платежная ведомость;
• — отчет по выполненным продажам;
• — отчет по клиентам;
• — счет-фактура;
• — финансовый отчет;
• — справочник товаров;
• — контакт;
• — справочник цен.

Хранилища данных диаграммы потоков, данных становятся сущностями концептуальной модели. Для формирования данных о заявках, используется сущность «Лист-заявка». Атрибуты сущности:

• — номер заявки — первичный ключ;
• — дату формирования;
• — количество;
• — стоимость;
• — описание заказа.

Для формирования данных о заявке, используется сущность «заказ». Атрибуты сущности:

• — номер заказа — первичный ключ;
• — дату формирования.

Для ведения справочника продуктов и цен введена сущность «Справочник продуктов», которая имеет следующие атрибуты:

• — номер продуктов — первичный ключ;
• — наименование продуктов;
• — цена.

Для ведения справочника клиент введена сущность «Клиент», которая имеет следующие атрибуты:

• — номер клиента — первичный ключ;
• — ФИО;
• — физическое или юридическое лицо.

Для хранения контактной информации о клиенте введена сущность «Контакт», которая имеет следующие атрибуты:

• — номер контакта — первичный ключ;
• — телефон;
• — адрес;
• — ИНН;
• — Е-mail;

Для ведения справочника товаров введена сущность «Справочник товаров», которая имеет следующие атрибуты:

• — номер — первичный ключ;
• — наименование;
• — стоимость.

Для ведения справочника введена сущность «Справочник», которая имеет следующие атрибуты:

• — номер — первичный ключ;
• — наименование;
• — описание;
• — стоимость.

Для формирования данных о заявке, используется сущность «Заявка». Атрибуты сущности:

• — номер заявки — первичный ключ;
• — дату формирования.

Для составления платежной ведомости, используется сущность «Платежная ведомость». Атрибуты сущности:

• — номер ведомости — первичный ключ;
• — дату формирования.

Для составления отчета менеджера, используется сущность «Отчет». Атрибуты сущности:

• — номер отчетапервичный ключ;
• — дату формирования;
• — общая стоимость.

Для составления отчета по клиентам, используется сущность «Отчет по клиентам». Атрибуты сущности:

• — номер отчета по услугам — первичный ключ;
• — дату формирования.

Для составления счет-фактуры, используется сущность «Счет-фактура». Атрибуты сущности:

• — номер счет-фактуры — первичный ключ;
• — дату формирования.

Для составления финансового отчета, используется сущность «Финансовый отчет». Атрибуты сущности:

• — номер отчета по услугам — первичный ключ;
• — дату формирования.

Рис. 1.10. Общая схема сущностей БД ООО «Автошины»

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

Таблица 5. Описание связей сущностей БД.

После проведенного анализа построим концептуальную модель данных с использованием Microsoft Visio 2003. При проектировании БД в реляционной СУБД основной целью разработки логической модели данных является создание точного представления данных, связей между ними и требуемых ограничений. Создание логической модели включает в себя: нормализация сущностей и разрешение неспецифических отношений (отношений «многие-ко-многим»). Для достижения этой цели необходимо, прежде всего, определить подходящий набор отношений. Метод, который используется для решения данной задачи, называется нормализацией. Нормализация — формальный метод анализа отношений на основе их первичных ключей и существующих функциональных зависимостей. Он включает ряд правил, которые могут использоваться для проверки отдельных отношений таким образом, чтобы вся БД могла быть нормализована до желаемой степени нормализации.

Зачастую нормализация осуществляется в несколько последовательно выполняющихся этапов, каждый из которых соответствует некоторой нормальной форме, обладающей определенными свойствами. В ходе нормализации формат отношений становится менее уязвимым по отношению к аномалиям обновления. Преобразуем концептуальную модель в логическую модель путём проведения нормализации и удаления нежелательных элементов (связей «многие-ко-многим» и множественных атрибутов). Первая нормальная форма. Приведем отношения к первой нормальной форме. Отношение находится в первой нормальной форме тогда и только тогда, когда все используемые домены содержат только скалярные значения. Все данные отношения находятся в первой нормальной форме. Теперь приведем отношения ко второй нормальной форме. Отношение находится во второй нормальной форме тогда, когда отношение находится в первой нормальной форме, и каждый неключевой атрибут неприводимо зависит от первичного ключа. Поскольку сущности в концептуальной модели не имеют составных ключей, то все отношения находятся во второй нормальной форме. Приведем отношения к третьей нормальной форме. Для этого устраним транзитивные зависимости, то есть если в некоторых отношениях обнаружена зависимость неключевых атрибутов от других неключевых атрибутов, то необходимо провести декомпозицию этих отношений. Так как сущности в концептуальной модели не имеют транзитивных зависимостей, то все отношения находятся в третьей нормальной форме. Четвертая нормальная форма — нормальная форма Бойса-Кода. Для проверки нахождения отношений в нормальной форме Бойса-Кода необходимо найти все детерминанты и убедиться, что они являются потенциальными ключами. Проанализировав детерминанты, можно сделать вывод, что отношения находятся в нормальной форме Бойса-Кода. Пятая нормальная форма. Отношение находится в пятой нормальной форме если оно находится в нормальной форме Бойса-Кода и в нем отсутствуют многозначные зависимости не являющиеся функциональными зависимостями. Данное отношение не содержит связи многие-ко-многим поэтому оно находится в пятой нормальной форме. Отношение находится в шестой нормальной форме тогда и только тогда, когда любая зависимость по соединению в нем определяется только возможными ключами.

В результате проведенного анализа построим логическую модель. Логическая модель БД позволяет сформировать физическую модель. Основные таблицы: «Demand» (Заявка), «Contact» (Контакт), «Application» (Заявка), «order» (заказ), «Client report» (Отчет по клиетам), «Report on service» (Отчет), «Payroll» (Платежная ведомость), «Invoice» (Счет-фактура), «Financial statement» (Финансовый отчет). Справочники: «Client», «Reference book of the services», «Reference», «Ethereal block».

Таблица 6 «Client»

Таблица 7 «Demand»

Таблица 8 «Application»

Таблица 9 «order»

Таблица 10 «Client report»

Таблица 11 «Report»

Таблица 12 «Payroll»

Таблица 13 «Financial statement»

Таблица 14 " Invoice «

Таблица 15 «Reference»

Таблица 16 " Reference"

На данном этапе обеспечена целостность информации базы данных. Реляционная модель описывает некоторые характерные правила, которые можно ввести для обеспечения в реляционной базе данных целостности данных. Это — ограничение домена, ограничение таблицы и ссылочное ограничение. Каждое значение поля должно быть элементом домена. Целостность домена гарантирует, что база данных не содержит бессмысленных значений. Она обеспечивает то, что значение в столбце является элементом домена столбца, то есть допустимого множества его значений. Строка не будет включена в таблицу, пока каждое из значений ее столбцов не будет находиться в домене соответствующего столбца. Задание целостности домена осуществляется с помощью типов данных. Запись данных не может быть включена в таблицу, пока данные в каждом столбце не будут иметь корректный тип. Другим встроенным ограничением целостности данных является целостность всей таблицы, которая означает, что каждая строка в таблице должна быть уникальной. Если таблица имеет такое ограничение, то вы можете уникально идентифицировать каждую ее строку. приложение интерфейс программный Чтобы задать целостность всей таблицы, разработчик указывает в таблице столбец или группу столбцов, определяя их как первичный ключ. Уникальное значение первичного ключа должно содержаться в каждой строке таблицы. Неявно это означает, что каждая строка таблицы должна иметь первичный ключ, поскольку отсутствие значение, то есть NULL, не будет отличаться от других значений NULL. Таблица может иметь только один первичный ключ. Во многих случаях разработчикам требуется устранить дублирующие значения и из других столбцов. Для этого разработчик может выделить другой ключевой столбец — задать альтернативный или уникальный ключ. Как и в основном ключе, дублирующих значений в альтернативном ключе таблица содержать не может. Ограничения целостности позволяют легко задать целостность таблицы, и всей базы данных в целом. Обеспечение синхронизации связанных таблиц. Ссылочная целостность определяет соотношения между различными столбцами и таблицами в реляционной базе данных. Такое название она получила, поскольку значения в одном столбце или наборе столбцов ссылаются на значения другого столбца или набора столбцов, либо должны совпадать с ними. При описании ссылочной целостности встретятся новые термины. Столбец, от которого зависит другая таблица, называется внешним ключом. При этом другая таблица, называется родительским ключом (это должен быть первичный или уникальный ключ). Внешний ключ находится в дочерней или детальной таблице, а родительский ключ — в основной таблице. Возможность связывать значения в различных таблицах и поддерживать отношения ссылочной целостности — это очень важная характеристика реляционных баз данных. Благодаря возможности связывания таблиц серверы реляционных СУБД могут очень эффективно хранить данные. В качестве рабочего инструмента для миграции БД предприятия на платформу корпоративного портала используем Visual Studio, последовательность шагов переноса данных представлена на рис. 1.11−1.13.

Рис. 1.11. Ссылка на добавленные пространства имен.

Рис. 1.12. Создание нового консольного приложения на C#.

Рис. 1.13. Создание нового пространства имен MySql.Data.

Запускаем на выполнение следующий программный код:

using System;

using System. Text;

using MySql.Data.MySqlClient;

using System. Data;

using System. Diagnostics;

using System.Data.SqlClient;

class Program.

{.

static MySqlConnection mySqlCnn;

static SqlConnection sqlSrvCnn;

static void Main (string[] args).

{.

sqlSrvCnn = new SqlConnection (@" server=(local)SQLExpress;database=bitrix;trusted_connection=true;MultipleActiveResultSets=true");

sqlSrvCnn.Open ();

mySqlCnn = new MySqlConnection («server=127.0.0.1;port=31 006;uid=root;pwd=;database=bsm_demo;Pooling=False»);

mySqlCnn.Open ();

DisEnableFKConstraints (true);

DataTable tblList = GetSourceTablesFromMySQLDB ();

CleanDestTablesInSQLSrvDB (tblList);

TransferData (tblList);

DisEnableFKConstraints (false);

mySqlCnn.Close ();

sqlSrvCnn.Close ();

}.

/// Копирует данные из таблицы в MySQL в одноименную таблицу в SQL Server.

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

/// Имя таблицы.

static void CopyDataFromMySQLTblToCorrespondingSQLSrvTbl (string tblName).

{.

//Читаем по порядку поля в таблице-назначения.

SqlCommand sqlSrvCmd = sqlSrvCnn. CreateCommand ();

sqlSrvCmd.CommandText = «select name from sys. columns where object_id = object_id (@tblName) order by column_id» ;

sqlSrvCmd.Parameters.AddWithValue («@tblName», tblName);

SqlDataReader sqlSrvDr = sqlSrvCmd. ExecuteReader (CommandBehavior.SingleResult);

//Составляем строку запроса для источника, перечисляя туда поля в том порядке, как они следуют в назначении.

StringBuilder mySqlCmdText = new StringBuilder («select «);

//Имя поля заключаем в аналог квадратных скобок — на случай, если оно будет совпадать с одним из зарезервированых слов MySQL.

while (sqlSrvDr.Read ()) mySqlCmdText. Append («`» + sqlSrvDr. GetSqlString (0).Value + «`,»);

sqlSrvDr.Close ();

mySqlCmdText.Remove (mySqlCmdText.Length — 1, 1);

mySqlCmdText.Append («from «+ tblName);

MySqlCommand mySqlCmd = new MySqlCommand (mySqlCmdText.ToString (), mySqlCnn);

MySqlDataReader mySqlDr = mySqlCmd. ExecuteReader ();

SqlBulkCopy bcp = new SqlBulkCopy (sqlSrvCnn, SqlBulkCopyOptions. KeepIdentity, null);

//KeepIdentity означает set identity_insert on/off.

//Поскольку в mySqlDr поля идут в том же порядке, что и в назначении, SqlBulkCopy. ColumnMappings не требуется.

bcp.DestinationTableName = tblName;

// Заправляем шланг ридера объекту SqlBulkCopy, чтобы он качал из него содержимое в bcp.DestinationTableName.

bcp.WriteToServer (mySqlDr);

mySqlDr.Close ();

}.

/// Получает список таблиц из MySQLной базы.

/// Список таблиц.

static DataTable GetSourceTablesFromMySQLDB ().

{.

DataTable tbl = new DataTable ();

tbl.Load (new MySqlCommand («show tables», mySqlCnn).ExecuteReader ());

return tbl;

}.

/// Удаляет в каждой таблице из списка все ее записи.

/// Список таблиц.

static void CleanDestTablesInSQLSrvDB (DataTable tblList).

{.

Debug.WriteLine («Очистка таблиц назначения…»);

foreach (DataRow r in tblList. Rows).

{.

new SqlCommand («delete «+ r[0]. ToString (), sqlSrvCnn).ExecuteNonQuery ();

Debug.WriteLine («Очищена таблица «+ r[0]. ToString ());

}.

Debug.WriteLine («Очистка закончена.»);

}.

static void TransferData (DataTable tblList).

{.

Debug.WriteLine («Загрузка данных…»);

foreach (DataRow r in tblList. Rows).

{.

CopyDataFromMySQLTblToCorrespondingSQLSrvTbl (r[0]. ToString ());

Debug.WriteLine («Перенесена таблица «+ r[0]. ToString ());

}.

Debug.WriteLine («Загрузка завершена.»);

}.

/// Процедура отключает/включает все ограничения внешнего ключа над таблицами в БД SQL Server.

/// Если да, то отключить, нет — включить.

static void DisEnableFKConstraints (bool switchOff).

{.

string prefix = switchOff? «От»: «В» ;

Debug.WriteLine (prefix + «ключение FK-ограничений…»);

SqlDataReader sdr = new SqlCommand («select name, object_name (parent_object_id) from sys. foreign_keys», sqlSrvCnn).ExecuteReader ();

while (sdr.Read ()).

{.

string fkName = sdr. GetString (0), tblName = sdr. GetString (1);

new SqlCommand (String.Format («alter table {0} {1}check constraint {2}», tblName, switchOff? «no»: «», fkName), sqlSrvCnn).ExecuteNonQuery ();

Debug.WriteLine (String.Format («{0}ключено ограничение {1} в таблице {2}», prefix, fkName, tblName));

}.

sdr.Close ();

Debug.WriteLine (prefix + «ключение FK-ограничений завершено.»);