Разработка базы данных торговой организации

     2. Определение таблиц, которые должна содержать база данных

Один из наиболее сложных этапов в процессе создания базы данных -  разработка таблиц, так как результаты, которые должна выдавать база данных не всегда дают полное представление о структуре таблицы.

Таблицы должны содержать всю информацию разрабатываемой базы. В моем случае это Клиенты, Товары, Описание товаров, Выполненные 

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

    3. Присвоение ключевых полей

Для связи данных из разных таблиц, например, данные о заказчике и продукции, каждая таблица должна содержать набор полей или поле, где будет задаваться индивидуальное значение каждой записи в таблице. Такое поле или набор полей называют основным ключом. Именно благодаря ключам будет функционировать база данных, сопоставляя, связывая и формируя информацию из разных  таблиц. Количество ключей варьируется от одного до нескольких. Вообще, ключ – это минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности.

 

   4. Редактирование структуры базы данных

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

5.  Добавление данных и создание других объектов базы данных

Если структуры  таблиц отвечают поставленным требованиям, то можно вводить все данные (в режиме конструктора таблиц). После ввода создаются любые запросы, формы, отчеты, макросы и модули (удобнее, проще и правильнее создавать все с помощью мастеров).  

2. Инфологическая  модель

 

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

Определяют три основные класса сущностей:

• стержневые
• ассоциативные
• характеристические.

   Стержневая  сущность – независимая сущность, которая имеет независимое существование, хотя может обозначать другие сущности.

   Характеристическая  сущность (характеристика) – это связь вида "многие-к-одному" или "одна-к-одной" между двумя сущностями (частный случай ассоциации). Цель характеристики состоит в описании или уточнении некоторой другой сущности предметной области.

   Ассоциативная сущность (ассоциация) – это связь вида "многие-ко-многим" между двумя или более сущностями или экземплярами сущности.

   Это теория. Для наглядности покажу на примере  торговой организации: 

   Стержневая  сущность

    «Заказ», «Заказчик», «Поставщик»

    Заказ (Заказ, код_заказа, количество, цена,  характеристика) 

   Заказчик  (Заказчик, телефон, адрес, название_фирмы) 

   Поставщик (ФИО,  телефон, адрес, страна) 

  Характеристическая  сущность

   «Выполненные_заказы», «Заказанные_товары» 

  Выполненные_заказы (код_заказа, заказчик, дата_заказа, цена, дата_выполнения, количество)

  Заказанные_товары (код_товара, количество)

2. Даталогическая  модель

1. Структура моей базы данных

Таблицы

Моя База Данных содержит 7 таблиц:

      -Товар

      - Производитель_товара

      - Описание_товара

      - Клиенты

      - Заказы

      - Заказанные_товары

     - Выполненные заказы

Во всех таблицах в режиме конструктора указываются первичные или внешние ключи.  

Таблица Товар: предназначена для хранения всех товаров с полным  их описанием. Например, кем произведены, по какой цене и в каком количестве.

Номер – номер товара. Поле является счетчиком.

Тип -  тип товара. Он берется из таблицы Описание_товара

Производитель – производитель товара. Берется из таблицы производитель_товаров.

Характеристика – поле, где котором содержится описание товара. Данные вводятся вручную в режиме конструктора.

Цена – цена товара за одну единицу. Значение вводится вручную.

Количество – количество товаров. Если значение равно нулю, то товара нет в наличие. Цена вводится от руки. Чтобы систематизировать столбец, надо указать формат поля.

 

Дата  поставки – день, месяц и год поставки товара. Вводится вручную.

Количество  проданных товаров – от руки вводится количество товара. Поле заполняется с помощью запроса (заказанные_товары и клиенты)

 

Таблица Производитель_товара: содержит 4 поля:

Производитель – Поставщик фирма-производитель товара.

Адрес, страна и телефон – более подробная информация. Все поля таблицы заполняются пользователем.

Таблица Описание_товара: состоит из двух полей:

Тип – тип товара (например: шубы, шорты и т.п.)

Описание  типа – поле предоставляет более полную информацию о товаре.  

Таблица Клиенты: дает описание всех клиентов данной организации.

В таблице указывается  ФИО,  адрес и телефон клиента.

Таблица Заказы: состоит из четырех полей :

Код заказа – код текущего заказа (тип поля – счетчик)

Фирма – заказчики (представители фирм). Данные берутся из таблицы Клиенты.

Дата  заказа – дата поступления заказа, данное поле заполняется автоматически.

Выполнен – Да / Нет. Если в этом поле стоит «галочка», то данный заказ уже выполнен (значение true). 

Таблица Заказанные_товары: содержит три поля :

Номер -  код заказа.

КодТовара – код данного товара. Берется из таблицы Товар и вводится автоматически.

Количество – количество заказанного товара, которое не должно превышать количество товаров данного типа  в таблице Товар. 

Таблица Выполненные заказы: содержит шесть полей, заполняется с помощью запроса и дает информацию про выполненные товары.

Код – код выполненного заказа

Фирма – название фирмы-заказчика.

Дата  заказа – дата поступления заказа.

Дата  выполнения – дата выполнения заказа.

Количество – общее количество заказанных товаров любого типа.

Сумма заказа – стоимость всех товаров в заказе. 
 
 
 
 

2.2 Нормализация

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

Можно выделить 4 основных правила, которыми следует руководствоваться при проектировании и последующей нормализации таблиц базы данных: 

1. Каждое  поле любой таблицы должно быть уникальным.
2. Каждая таблица должна иметь уникальный первичный ключ, который может состоять из одного или нескольких полей таблицы.
3. Для каждого значения первичного ключа должно быть одно и только одно значение любого из столбцов данных, и это значение должно относиться к объекту таблицы.
4. Должна иметься возможность изменять значения любого поля (не входящего в первичный ключ), и это не должно повлечь за собой изменение другого поля.

 
 

Созданная мною таблица удовлетворяет вышеизложенным требованиям:

1 НФ (Нормальная Форма):

 

2 НФ:

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

3 НФ:

 все неключевые  атрибуты отношения взаимно независимы и полностью зависят от первичного ключа.

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

2.3 Схема данных

Отношения – это правила, поддерживаемые на уровне механизма реализации СУБД. Различают три типа отношений: 

• Отношение «один-к-одному»: для каждой строки в одной таблице существует не более одной строки связанной таблицы.
• Отношение «один-ко-многим»: одна таблица не содержит вообще или имеет набор связанных «дочерних» записей из другой таблицы.
• Отношение «многие-ко-многим»: для каждой строки первой таблицы может существовать набор строк в другой таблице и наоборот. Такая связь организуется, как правило, при помощи третьей, связующей таблицы, содержащей значения первичных ключей обеих таблиц в качестве внешних ключей.

При разработке БД необходимо принимать во внимание правила обеспечения целостности данных (обеспечивает каскадное обновление

записей в связанных таблицах) 

В моей схеме  данных таблицы связаны следующим образом. При добавлении нового товара, продавец выбирает тип (товара), который с помощью мастера подстановки берется из таблицы Описание_товара. 
 

Также продавец выбирает производителя (из таблицы Производитель_товара). Далее он от руки вводит характеристику товара, его цену и количество в таблицу Товар.

При поступлении  нового заказа, продавец в таблицу Заказы вводит заказанные товары, нажав на «галочку» в графе «выполнен»,  а затем выбирает Фирму – заказчика.

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

Ниже представлена моя схема данных:

 

Таблица Выполненные заказы  заполняется с помощью запроса, которому не требуются никакие связи, поэтому в данной схеме данных  этой таблицы нет.