СОДЕРЖАНИЕ
Задание на работу. 3

ВВЕДЕНИЕ. 4

1. Постановка задачи. 5

2.  Назначение и предметная область. 6

3.  Построение инфологической модели на языке "Таблицы-связи". 10

4. Построение инфологической модели на реляционную модель данных. 16

ЗАКЛЮЧЕНИЯ И ВЫВОДЫ.. 20

ЛИТЕРАТУРА.. 21

Задание на работу

Тема предметной области - Сведения о торгово-посреднической организации. Реляционная модель данных. Отражение модель "Таблицы-связи" на реляционную модель данных.

На основе анализа предметной области,  согласно поставленной задачи разработать информационную модель.

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

ВВЕДЕНИЕ

Процесс проектирования БД на основе принципов нормализации представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формализованному описанию объектов предметной области в терминах некоторой модели.

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

Инфологическое проектирование, прежде всего, связано с попыткой представления семантики предметной области в модели БД.

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

1. Постановка задачи

На основе анализа предметной области Сведения о торгово-посреднической организации,  разработать информационную модель.

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

2.  Назначение и предметная область

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

Различают следующие виды торгово-посреднических фирм: торговые, комиссионные, агентские, бро­керские.

В данной работе рассмотрена торговая оптовая фирма.

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

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

К основным торгово-посредническим операциям относятся операции по перепродажи.

Операции по перепродаже - это операции, которые осуществляются торговым посредником от своего имени и за свой счет. Это означает, что торговый посредник сам выступает стороной договора как с экспортером (экспортер-произво­дитель), так и с конечным покупателем, и становится собственником товара после его оплаты.

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

- Номер договора;

- Условия оплаты (может быть предоплата, отсрочка, наличные или безналичные);

- Дата составления договора купли-продажи;

- Наименование производителя/поставщика (название организации);

- ФИО директора этой организации;

- Адрес (где располагается фирма производителя/поставщика);

- Телефон директора организации;

- ИИН организации производителя/поставщика;

- Наименование розничной торговой фирмы;

- ФИО директора фирмы;

- Адрес (где располагается розничная торговая фирма);

- Телефон директора фирмы;

- ИИН организации.

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

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

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

          После этого формируется счет-фактура с полной информацией о товаре:

- Артикул товара;

- Наименование товара;

- Цена за 1 ед. товара;

- Количество приобретенного товара.

         Бланк счет фактуры представлен в приложении №1.

         При осуществлении доставки товара на склад формируется Товарно-транспортная накладная (ТТН), для которой необходима следующая информация:

         - № заказа;

         - Наименование приобретенного товара;

         - Наименование поставщика;

         - Дата поставки;

- Цена за 1 ед. товара;

- Количество.

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

Формируется заказ, получая товар, организации предоставляют  сопроводительные документы (входные): договор купли-продажи;  ИНН; ТТН; счет-фактура; расходная накладная.

Организация, оприходует товар, размещает его на складе и продает клиенту (Рисунок 1).



Рисунок 1 – Схема движения товара.
При отпуске товара также заключается договор купли-продажи. Затем, после получения заявок от клиента, товар отбирается на складе и уже формируется выходные документы - расходная накладная, счет – фактура и ТТН.



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

- Номер склада (у одной организации может быть несколько складов);

- Наименование товар, который хранится на складе;

- Номер стеллажа, на котором находится товар;

- Номер полки на стеллаже (каждой полке соответствует одно наименование товара).

3.  Построение инфологической модели на языке "Таблицы-связи".

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

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

Для построения базы данных для торгово-посреднической организации необходима информация о заказах, сделанных самой организацией, а именно:

Дата заказа

Наименование фирмы

ФИО директора

Телефон

Адрес

ИНН

Вид договора

Дата составления

Условия оплаты

Дата доставки

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

Производитель

Цена товара за 1 ед.

Количество.
Так же необходима информация о заявках от клиентов, а именно:

Дата заявки

Наименование фирмы

ФИО директора

Телефон

Адрес

ИНН

Вид договора

Дата составления

Условия оплаты

Дата отгрузки

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

Производитель

Цена товара за 1 ед.

Количество

Количество на складе

Наименование склада

Номер стеллажа

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

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

Произведем нормализацию отношений, чтобы можно было:

- обеспечить быстрый доступ к данным;

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

- обеспечить целостность данных, т.о. чтобы при изменении одних объектов автоматически происходило соответствующее изменение связанных с ними объектов.

Приведем БД к 1НФ.

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

Добавим в таблицу Заказы поле Код заказа, что позволит однозначно идентифицировать каждый из заказов.

Таблица Заказы содержит 3 группы повторяющихся полей:

Поля, характеризующие поставщика (производителя):

 - Наименование фирмы

- ФИО директора

- Телефон

- Адрес

- ИНН

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

Поля,  характеризующие товар:

- Наименование товара

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

- Цена товара за 1 ед.

- Количество на кладе

Вынесем их в отдельную таблицу Товары и добавим новое поле Код товара.

Поля,  характеризующие договоры:

- Вид договора

- Дата составления

- Условия оплаты

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

Таблица Заявки содержит 4 группы повторяющихся полей:

Поля, характеризующие клиента:

- Наименование фирмы

- ФИО директора

- Телефон

- Адрес

- ИНН

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

Поля, характеризующие товар и договоры уже вынесены в таблицы Товары и Договоры.

Поля, характеризующие склады:

- Наименование склада

- Номер стеллажа

- Номер полки на стеллаже.

Вынесем их в отдельную таблицу Склады  и добавим новое поле Код склада.

Т.к. связь между таблицами происходит по совпадающим полям, добавим в таблицу Заказы поля Код поставщика и Код товара, в таблицу Заявка поле Код клиента и Код товара, в таблицу Договоры поле Код клиента(поставщика),  в таблицу Склады поле Код товара для организации связи.

2 НФ.

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

Определим ключевые поля:

Для таблицы Заказы ключом является поле Код заказа, таблица Заявки – Код заявки, таблица Клиенты – Код клиента, таблица Поставщики – Код поставщика, таблица Договоры – Код договора, таблица Товары – Код товара, таблица Склады – Код склада.

3НФ.

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

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

Все таблицы, приведенные во 2 НФ соответствуют 3 НФ, т.к. в каждой таблице нет полей, которые не зависят от ключа.

При нормализации отношений можно выделить следующие сущности:

- Клиенты (Код клиента, Наименование фирмы, ФИО директора, Адрес, Телефон, ИНН)

Эта сущность отводится для хранения сведений о клиентах, с которыми работает организация, для которых осуществляет доставку товара.

- Поставщики (Код поставщика, Наименование фирмы,  ФИО директора Адрес, Телефон, ИНН). 

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

- Товары (Код товара, Наименование товара, Цена за 1 ед., Производитель, Количество на складе)

Хранит сведения о товаре, количестве на складе для учета продукции.

- Заявки (Код заявки, Код клиента,  Дата заявки, Код товара, Количество, Дата отгрузки)

Сведения о заявках (которые утвердил клиент), на основании заявки осуществляется изъятие продукции со склада.

- Заказы (Код заказа, Дата заказа, Код поставщика, Код товара, Количество, Дата доставки)

Эта сущность хранит сведения о поступлениях товара на склад от определенного поставщика/производителя.

- Договоры (Код договора, Вид договора, Дата составления, Код клиента (поставщика), Условия оплаты)

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

- Склады (Код товара, Код склада, номер стеллажа, номер полки на стеллаже).

На основании данных сущностей строим инфологическую модель в БД.

                           

Поставщики

Договоры

Клиенты

Рисунок 3 – Инфологическая модель базы данных  торгово-посреднической организации, построенная с помощью языка "Таблицы-связи".

4. Построение инфологической модели на реляционную модель данных

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

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

Реляционная база данных – это совокупность отношений, содержащих всю информацию, которая должна храниться в БД, следовательно, отражение модели "Таблицы-связи" на реляционную модель данных будет выглядеть в виде совокупности таблиц. Каждая реляционная таблица представляет собой двумерный массив и обладает следующими свойствами:

- каждый элемент таблицы – один элемент данных;

- все элементы в столбце  имеют  одинаковый тип и длину;

- каждый столбец имеет уникальное имя;

- одинаковые строки в таблице отсутствуют;

- порядок следования строк и столбцов может быть произвольным.

Объект - элемент ИС, информация о котором сохраняется в ИС. В реляционной теории БД объект называется сущностью.

Атрибуты объекта - свойства характеризующие объект.

Атрибут записанный на каком-либо носителе информации называют элементом данных, полем данных или просто полем.

Запись совокупность характеристик объекта или кортеж.

Таблица некоторая структурированная информация, содержащая характеристики объекта или класса объектов.

Каждая строка является записью, а каждый столбец полем.

Тип данных характеризует вид хранящихся данных. Различают символьные, числовые данные, даты, время и т.д.

Тип данных вид хранящихся данных. Различают символьные, числовые данные, даты, время и т.д.

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

База данных совокупность таблиц объединенных вместе по какому-либо признаку.

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

Если отношение имеет более одного возможного ключа, тогда выделяют один ключ, называемый первичным. И наоборот, если отношение не имеет ни одного атрибута, который бы полностью определил объект (строку, кортеж) отношения, то определяется составной ключ, который схематически отображают двойной вертикальной чертой.

Ключ-это такой элемент, по которому можно определить значения других полей.

Пример отношения в реляционной модели данных: Таблица Заказы, имеет первичный ключ Код заказа. Поля: Дата заказа, Код поставщика, Код товара, количество, Дата поставки являются атрибутами в данной таблице.
Таблица «Заказы».
Все информационные объекты предметной области связаны между собой. Существует 3 вида связи:

- один к одному (1:1);

- один ко многим (1:М);

- многие ко многим (М:М).

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

Связь 1:1 предполагает, что в каждый момент времени одному экземпляру информационного объекта А соответствует не более одного экземпляра информационного объекта В. Каждая запись одной таблицы соответствует одной записи в другой таблице

При связи 1:М одному экземпляру информационного объекта А соответствует 0,1 или более экземпляров объекта В, но каждый экземпляр объекта В связан не более чем с 1 экземпляром объекта А. Каждой записи в одной таблице соответствует несколько записей в другой таблице.

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

Между информационными объектами Клиенты и Договоры существует связь 1:М. Один клиент может заключить несколько договоров (например, с разницей в условии оплаты: предоплата или отсрочка). Так же между объектам Поставщики и Договоры существует связь 1:М.

Между информационными объектами Клиенты и Заявки существует связь 1:М. Один клиент может вносить сколько угодно заявок.

Между информационными объектами Товары и Заявки существует связь 1:М. Один и тот же товар может включаться в любое количество заявок, либо заказов.

Между информационными объектами Товары и Склады существует связь 1:1. Товар занимает определенное место на складе.

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

ЗАКЛЮЧЕНИЯ И ВЫВОДЫ

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

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

ЛИТЕРАТУРА

1.      Кириллов В.В. Основы проектирования реляционных баз данных

СПб.: ИТМО, 1994. – 50 с.

2. Джексон Г. Проектирование реляционных баз данных для использования с микроЭВМ. -М.: Мир, 1991. – 252 с.

3. Бойко В.В., Савинков В.М. Проектирование баз данных информационных систем. – М.: Финансы и статистика, 1989. – 351 с.

4.   Мейер М. Теория реляционных баз данных. – М.: Мир, 1987. – 608 с.

5.   Серебрякова Т.А. Модели данных. Методические указания. – ТОГУ, 2006. – 65 с.