Основные понятия и принципы программирования баз данных

   -Справки  -  получение/выдача   различных  справок  как   заказчику   так   и поставщику.

   -Товар - присутствует на основании заявки и договора с поставщиком.

2.Определение взаимосвязей.

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

   Следующий представляющий для нас интерес  объект —  Товар.  Этот  объект имеет свойства «уникальный ключ товара», «наименование товара».

   Второй  рассматриваемый объект  —  Поставщик.  Его  свойствами  являются

   «уникальный ключ поставщика», «наименование поставщика».

       Третий рассматриваемый  объект  —  Заказчик.  Его  свойствами  являются «уникальный ключ заказчика», «наименование заказчика».

   Взаимосвязь «один к одному» (между двумя  типами объектов)

   Допустим, в определенный момент времени  один  заказчик  может  сделать только  один  заказ.  В  этом  случае  между  объектами  Заказчик  и   Товар устанавливается взаимосвязь «один к одному».

   Взаимосвязь «один ко многим» (между двумя  типами объектов)

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

   Взаимосвязь «один к одному» (между двумя  свойствами)

   Мы  предполагаем, что ключ  (номер)  магазина  является  его  уникальным идентификатором, то есть он не изменяется  и  при  последующих  поступлениях заказов от данного магазина. Если наряду с номером магазина  в  базе  данных хранится и другой его уникальный идентификатор (например, адрес),  то  между такими двумя уникальными идентификаторами  существует  взаимосвязь  «один  к одному».

   Взаимосвязь «один ко многим» (между двумя  свойствами)

   Имя  поставщика  и  его  номер  существуют  совместно.  Поставщиков   с одинаковыми именами может быть много, но все  они  имеют  различные  номера. Каждому  поставщику  присваивается  уникальный  номер.  Это  означает,   что данному номеру поставщика соответствует только одно имя.  Взаимосвязь  «один ко многим» обозначается  одинарной  стрелкой  в  направлении  к «одному»  и двойной стрелкой в направлении ко «многим».

   Первоначальная  схема данных

|Функциональная  |Исследование токов                  |Данные выявленные в   |

|модель          |Данных                              |ходе разработки       |

|Отдел обработки |                                    |Заявки                |

|заявок          |                                    |                      |

|                |                                    |Договора              |

|Договоров       |                                    |Поставщики            |

|                |                                    |Заказчики             |

|Ведение счетов  |                                    |Счета                 |

|Погрузка        |                                    |Накладные             |

|                |                                    |Товар                 |

|                |                                    |Инвентаризация        |

|                |                                    |Справки               | 

   Определение объектов

   Выделим следующие объекты:

   1. товар - (Т);

   2. заказчик - (З);

   3. поставщик - (П);

   4. сета - (С);

   5. договор - (Д);

   6. накладные - (Н).

   Первоначальное графическое представление концептуальной модели

|                        |Т                       |                        |

|З                       |                        |П                       |

|                        |С                       |                        |

|Н                       |                        |Д                       |

   Задание первичных и альтернативных ключей, определение свойств объектов

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

   Приведение модели к требуемому первому уровню нормальной формы

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

   Нормализация  информационной модели выполняется  в несколько этапов.

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

   Например, может наблюдаться такая парадоксальная ситуация.

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

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

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

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

   Транзитивная  зависимость  выявляет   дублирование   данных   в   одном отношении. Если А, В и С - три свойства одного отношения и С зависит  от  В, а В от А, то говорят, что С  транзитивно  зависит  от  А.  Преобразование  в третью нормальную форму происходит за счет  разделения  исходного  отношения на два.

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

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

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

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

ЗАКЛЮЧЕНИЕ

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