Работа с базами данных на C#. Урок 4. Немного теории.

И так, мы уже научились создавать базу данных SQL, просматривать и редактировать ее средствами языка C# и Visual Studio 2010 (см. предыдущий урок). Что бы идти дальше, нам надо немного изучить теорию. И так, давайте начнем с терминов и определений.

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

Строки таблицы называются записи. Все они имеют одинаковую структуру, они состоят из полей, в которых хранятся атрибуты объетка:

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

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

• Добавление записей в таблицы.

• Удаление записей из таблицы.

• Обновление данных.

• Поиск данных.

• Управление данными.

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

Прежде чем автоматизировать предметную область с использование баз данных (разработать СУБД или специальное приложение), необходимо сначала спроектировать базу данных. Такое проектирование состоит из нескольких этапов:

• Анализ требований. На этом этапе находит ответы на следующие вопросы: Какие элементы данных должны храниться в БД? Кто и как будет с ними обращаться?

• Создание логической модели БД. На этом этапе определяется, как данные будут сгруппированы логически. Структура базы данных на этом этапе выражается в терминах прикладных объектов и отношений между ними.

• Создание физической структуры БД. На этом этапе непосредственно определяется, какие в базе данных будут таблицы и какие у них будут атрибуты.

Давайте рассмотрим пример проектирования базы данных для складского учета.

И так, анализ требований:

Допустим, в программе должны храниться следующие данные:

• Наименование товара.

• Цена товара.

• Номер приходной накладной.

• Номер расходной накладной.

• Дата приходной накладной.

• Дата расходной накладной.

• Количество товара, поступившего по накладной.

• Количество товара, списанного по накладной.

• Фамилия менеджера, которому отпущен товар.

• Остаток товара на складе.

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

Например, для нашего случая может быть вот такая функциональная спецификация:

• С программой будут работать кладовщик и бухгалтер.

• Одновременно могут работать два пользователя.

• Ассортимент товаров примерно 1000 наименований.

• В день выписывается примерно 100 накладных.

• Примерно раз в месяц в базу данных заводятся новые наименования товаров, примерно десять наименований.

• Каждая накладная в среднем имеет по 10 строк.

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

• Кладовщику нужно видеть цены товара в любое время.

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

Логическая модель.

В рамках данной задачи можно выделить следующие объекты:

• Товар.

• Документ складского учета (накладная).

• Таблица остатков товара.

• Таблица движений товара.

• Менеджер.

• Тип накладной.

• Строка накладной.

Между этими объектами может быть следующие отношения:

• Каждая накладная может содержать одну или несколько строк.

• Каждая накладная может иметь тип.

• Каждая строка накладной содержит один товар и его количество.

• Каждая накладная с типом "Расходная" связана с одним менеджером.

• Таблица движений содержит один или несколько товаров.

• Таблица остатков содержит один или несколько товаров.

Теперь перейдем к разработке физической структуры базы данных.

Таблица "Товары"

Таблица "Накладные"

Таблица "Типы накладных"

Таблица "Строки накладных"

Таблица "Менеджеры"

Таблица "Движения товаров"

Таблица "Остатки товаров"

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

Приведенные в статье скриншоты, являются цитатами и иллюстрациями  программного продукта "Microsoft Visual Studio 2010 Professional", авторское право на который принадлежит корпорации Microsoft..