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

управлять на уровне таблиц и столбцов. Эти права устанавливают владельцы

(owner) баз данных или объектов баз данных. Некоторые системы разрешают

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

В многопользовательских системах обычно имеется пользователь с правами

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

(system administrator), или администратор базы данных (database

administrator). Этот пользователь обычно обладает широкими правами на

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

поддержкой и администрированием базы данных.

В качестве дополнительного механизма обеспечения безопасности могут

выступать и виртуальные таблицы. Пользователи могут разрешать доступ только

к определенному подмножеству своих данных, включенному в виртуальную

таблицу.

2.1.8. Целостность

Целостность (integrity) - очень сложный и серьезный вопрос при

управлении реляционными базами данных. Несогласованность между данными

может возникать по целому ряду причин. Несогласованность или

противоречивость данных может возникать вследствие сбоя системы—проблемы с

аппаратным обеспечением, ошибки в программном обеспечении или логические

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

защищают данные от такого типа несогласованности, гарантируя, что команда

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

обычно называют управлением транзакциями (transaction management).

Другой тип целостности, называемый объектной целостностью (entity

integrity), связан с корректным проектированием базы данных. Объектная

целостность требует, чтобы ни один первичный ключ не имел нулевого

значения. Третий тип целостности, называемый ссылочной целостностью

(referential integrity), означает непротиворечивость между частями

информации, повторяющимися в разных таблицах. Например, если вы изменяете

неправильно введенный номер расчетного счета покупателя в одной таблице,

другие таблицы, содержащие эту же информацию, продолжают ссылаться на

старый номер, поэтому вы должны обновить и эти таблицы. Чрезвычайно важно,

чтобы при изменении информации в одном месте, она соответственно изменялась

и во всех других местах. Правила Кодда гласят, что системы управления

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

ссылочную целостность, но и позволять «вводить дополнительные ограничения

на целостность, отражающие специальные требования». Кроме того, по

определению Кодда, ограничения на целостность должны:

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

других целей;

. храниться в словаре данных, а не в программных приложениях.

Первоначально только несколько реализаций реляционных баз данных

удовлетворяли критериям Кодда на целостность, но ситуация постепенно

изменялась. Стандарт 1992 года (часто называемый «SQL92») поддерживает

ограничения, обеспечивающие ссылочную целостность и позволяющие задавать

бизнес правила. Эти возможности в том или ином виде реализованы в

большинстве систем.

2.2. Проектирование баз данных

Процесс, в ходе которого решается, какой вид будет у вновь создаваемой

базы данных, называется проектированием базы данных (database design).

Работа по проектированию базы данных включает выбор:

. таблиц, которые будут входить в базу данных,

. столбцов, принадлежащих каждой таблице,

. взаимосвязей между таблицами и столбцами.

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

структуры. В реляционной модели логическая структура базы абсолютно не

зависит от ее физической структуры и способа хранения. Логическая структура

также не определяется тем, что видит у себя на экране конечный пользователь

(это могут быть виртуальные таблицы, созданные разработчиком или

прикладными программами).

Конструирование баз данных на основе реляционной модели имеет ряд

важных преимуществ перед другими моделями.

. Независимость логической структуры от физического и пользовательского

представления.

. Гибкость структуры базы данных—конструктивные решения не ограничивают

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

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

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

взаимосвязях, содержащихся в базе, а не только о тех, которые планировались

первоначально.

С другой стороны, реляционные системы не имеют никаких встроенных

защитных механизмов против некорректных структурных решений и не умеют

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

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

процессе принятия структурных решений.

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

Часто при обсуждении вопросов проектирования реляционных баз данных

почти все внимание уделяется применению правил нормализации. В ходе

нормализации обеспечивается защита целостности данных путем устранения

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

«имеющей смысл», разбивается на две или более связанных таблиц, которые

могут быть «собраны вместе» с помощью операции объединения. Этот процесс

называется декомпозицией без потерь (non-loss decomposition) и просто

означает разделение таблицы на несколько меньших таблиц без потери

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

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

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

убедившись при этом, что не сделали каких-то фатальных ошибок. Понимание

основ процесса нормализации также может помочь в процессе проектирования

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

с нуля. Итак, как определить, какие столбцы должны располагаться в начале

таблицы. Общего правила на этот счет не существует. Однако здесь вам может

оказать существенную помощь моделирование зависимостей — анализ сущности

данных (в терминах объектов или вещей) и зависимостей между ними (один-к-

одному, один-ко-многим, многие-ко-многим).

На практике проектирование базы данных требует хорошего понимания

моделируемой предметной области, а также знаний в области моделирования

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

итеративным процессом, в ходе которого шаг за шагом достигается требуемый

результат, а иногда и пересматривается несколько шагов, переделывая

предыдущую работу с учетом появившихся новых потребностей. Вот примерная

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

1. Исследования информационной среды для моделирования.

. Откуда поступает информация и в каком виде?

. Как она будет вводиться в систему и кто этим будет заниматься?

. Как часто она изменяется?

. Какие параметры системы будут наиболее критическими с точки зрения

времени реакции на запрос и надежности?

. Изучение всех бумажных материалов, а также информационных файлов и форм,

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

. Уточнение, в каком виде информация должна извлекаться из базы данных — в

форме отчетов, заказов, статистической информации.

. Кому она будет предназначаться.

2. Создание списка объектов (вещей, которые будут предметом базы

данных) вместе с их свойствами и атрибутами. Объекты, скорее всего, должны

быть собраны в таблицы (каждая строка таблицы будет описывать один объект,

например организацию, счет или платежное поручение), свойства объектов

будут представлены столбцами таблицы (например, адрес компании, стоимость

дистрибутива).

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

между ними, называемый структурой данных (data structure), или диаграммой

зависимостей между объектами (E-R diagram).

4. Предварительно разобравшись с объектами и их атрибутами, надо

убедится, что каждый объект имеет атрибут (или группу атрибутов), по

которому однозначно можно идентифицировать любую строку в будущей таблице.

Этот идентификатор обычно называется первичным ключом. Если такового нет,

то для получения искусственного ключа следует создать дополнительный

столбец.

5. Затем должны быть рассмотрены зависимости между объектами.

. Имеются ли зависимости типа один-ко-многим (один заказчик может иметь

множество выписанных счетов, но каждый счет может быть выписан только на

одного заказчика) или многие-ко-многим?

. Есть ли возможности для объединения связанных таблиц? Для этого служат

внешние ключи (foreign key), столбцы в связанных таблицах с совпадающими

значениями первичных ключей.

6. Анализ структуры базы данных с точки зрения правил нормализации для

поиска логических ошибок. Исправление всех отклонений от нормальных форм

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

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

причины таких решений.

7. Непосредственному создание структуры базы данных и помещению в нее

некоторых прототипов данных. Обязательное экспериментирование с запросами,

изучение полученных результатов. Выполнение рядов тестов на

производительность, чтобы проверить разные технические решения.

8. Оцените базы данных с точки зрения того, удовлетворяют ли заказчика

полученные результаты.

2.2.2. Несколько слов о структуре базы данных.

I) Что такое «хорошая структура»

Хорошая структура — это, в первую очередь, «прозрачная» структура.

Проще говоря, хорошая структура:

. максимально упрощает взаимодействие с базой данных;

. гарантирует непротиворечивость данных;

. «выжимает» максимум производительности из системы.

Некоторые факторы, упрощающие понимание базы данных, не имеют строгих

технических определений и не являются частью процесса проектирования. Тем

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

время разделение данных на целый ряд небольших таблиц усложняет

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

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

нормализации. Хорошо разработанная база данных предотвращает ввод

противоречивой информации и случайное удаление данных. Это достигается за

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

целостности.

Наконец, хорошо разработанная база должна обладать достаточной

производительностью. Опять-таки здесь играет большую роль число столбцов в

таблицах: выборка данных будет проводиться медленнее, если информация

размешена

не в одной, а в нескольких таблицах. Однако большие таблицы могут

требовать

от системы обработки большего количества данных, чем это на самом деле

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

и размер таблиц существенно влияют на производительность. (Также с точки

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

выполняется индексирование и тип индексирования.) Индексирование в большей

мере является вопросом физического проектирования, нежели логического.

II) Плохая структура базы данных

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

. повышает риск введения в базу данных противоречивой информации;

. порождает избыточные данные;

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

заполненных данными таблиц.

Не существует идеального решения, полностью удовлетворяющего все

требования, предъявляемые при проектировании баз данных. Часто приходится

чем-то жертвовать, основываясь на требованиях и особенностях приложений,

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

2.3. Нормализация.

Вообще говоря, нормализация — это набор стандартов проектирования

данных, называемых нормальным и формами (normal forms). Общепринятыми

считаются пять нормальных форм, хотя их было предложено значительно больше.

Создание таблиц в соответствии с этими стандартами называется

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

Каждая последующая форма удовлетворяет требования предыдущей. Если

следовать первому правилу нормализации, то данные будут представлены в

первой нормальной форме. Если данные удовлетворяют третьему правилу

нормализации, они будут находиться в третьей нормальной форме (а также в

первой и второй формах).

Выполнение правил нормализации обычно приводит к разделению таблиц на

две или больше таблиц с меньшим числом столбцов, выделению отношений

первичный ключ—внешний ключ в меньшие таблицы, которые снова могут быть

соединены с помощью операции объединения.

Одним из основных результатов разделения таблиц в соответствии с

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

При этом в базе возможно возникновение одинаковых столбцов первичных и

внешних ключей. Такое преднамеренное дублирование — это не то же самое, что

избыточность. На самом деле поддержка непротиворечивости между первичными и

внешними ключами связана с понятием целостности данных.

Правила нормализации, подобно принципам объектного моделирования,

развивались в рамках теории баз данных. Большинство разработчиков баз

данных признают, что представление данных в третьей и четвертой нормальных

формах полностью удовлетворяет все их потребности.

2.3.1. Первая нормальная форма.

Первая нормальная форма требует, чтобы на любом пересечении строки и

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

Кроме того, в таблице, удовлетворяющей первой нормальной форме, не должно

быть повторяющихся групп.

В ряде случаев объектное моделирование приводит к тем же результатам,

так как в этом случае мы имеем отношение один-ко-многим (одна накладная -

много позиций).

2.3.2. Вторая нормальная форма

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

зависел от всего первичного ключа. Следовательно, таблица не должна

содержать не ключевых столбцов, зависящих только от части составного

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

чтобы все столбцы, не являющиеся первичными ключами (столбцы, описывающие

объект, но однозначно не идентифицирующие его), зависели от всего

первичного ключа, а не от его отдельных компонентов.

Суммируя вышесказанное, вторая нормальная форма требует, чтобы ни один

не ключевой столбец не зависел только от части первичного ключа. Это

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

столбцов, и неприменимо, когда первичный ключ образован только из одного

столбца.

2.3.3. Третья нормальная форма

Третья нормальная форма повышает требования второй нормальной формы:

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

форма требует, чтобы ни один не ключевой столбец не зависел от другого не

ключевого столбца. Любой не ключевой столбец должен зависеть только от

столбца первичного ключа.

Рассматривая структуру этих таблиц, вы увидите, что они удовлетворяют

как второй, так и третьей нормальной форме. Они удовлетворяют второй

нормальной форме, так как все не ключевые столбцы зависят от всего

первичного ключа, и третьей нормальной форме, так как все не ключевые

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

столбец зависит от ключа, всего ключа и ничего, кроме ключа.

2.3.4. Четвертая и пятая нормальные формы

Четвертая нормальная форма запрещает независимые отношения типа один-ко-

многим между ключевыми и не ключевыми столбцами. В качестве

примера рассмотрим несколько надуманный пример: с каждым заказчиком может

работать несколько кураторов и несколько курьеров, но между кураторами и

курьерами нет абсолютно никакой связи, хотя они естественным образом

связаны с заказчиком. Помещение этой разнородной информации в одну таблицу

может привести к появлению в ней пустых мест, так как курьеров может быть

больше, чем кураторов. Удаление данных о курьерах или кураторах также может

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

существовании зависимости между курьерами и кураторами, так как эти данные

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

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

форма доводит весь процесс нормализации до логического конца, разбивая

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

избыточности данных. Нормализованные таким образом таблицы обычно содержат

минимальное количество информации, помимо первичного ключа.

Преимуществом преобразования базы данных в пятую нормальную форму

является возможность управления целостностью. Поскольку при этом любой

фрагмент не ключевых данных (данных, не являющихся первичным или внешним

ключом) встречается в базе данных только один раз, не возникает никаких

проблем при их обновлении. Если, например, изменяется физический адрес

заказчика, соответствующие поправки нужно внести только в таблицу

«Заказчики», и не надо просматривать остальные таблицы на предмет поиска и

изменения в них значения соответствующего поля физический адрес.

Однако, поскольку каждая таблица в пятой нормальной форме имеет

минимальное число столбцов, то в них должны дублироваться одни и те же

ключи, обеспечивая возможности для объединения таблиц и получения полезной

информации.

Изменение значения единственного ключа уже является очень серьезной

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

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

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

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

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

эффективно при автоматизации финансового звена малого коммерческого

предприятия. Вышеизложенная теория и принципы управления реляционными

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

работы любого финансового подразделения предприятия. Основные принципы

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

наилучшее ее функционирование. Соблюдение принципов целостности,

безопасности и независимости данных, что дает нам реляционная модель,

позволяет организовать отказоустойчивую структуру данных, что так

необходимо для правильного и непрерывного функционирования финансовых

подразделений. Применение принципа нормализации к структуре данных дает

высокую гибкость при проектировании пользовательского интерфейса и

обеспечивает не избыточность данных, что особенно важно учитывая большой

объем информации обрабатываемый в повседневной работе финансовых

подразделений.

3. Общее описание базы данных

3.1. Задачи, выполняемые приложением «Бухгалтерия»

База данных «Бухгалтерия» предназначена для автоматизации работы

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

задание на реализацию базы данных входили следующие задачи:

1. Оформление, учет и выписка первичной бухгалтерской документации

(счетов) по основному профилю работы организации (системы КонсультантПлюс)

2. Оформление, учет и выписка вторичной отчетной документации (акты

приемки-сдачи, накладные, счета-фактуры, акты на информационно-программного

сопровождение, счета-фактуры на информационно-программного сопровождение),

фиксирование информации о приходе денежных средств по счетам, формирование

первичного авансового отчета по основному профилю работы организации

(системы КонсультантПлюс)

3. Оформление, учет и выписка первичной бухгалтерской документации

(счетов) по дополнительным заказам (программное и аппаратное обеспечение,

информационные услуги)

4. Оформление, учет и выписка вторичной отчетной документации (акты на

установку, накладные, счета-фактуры, акты на информационные услуги),

фиксирование информации о приходе денежных средств по счетам, формирование

первичного финансового отчета по дополнительным заказам организации

(программное и аппаратное обеспечение, информационные услуги)

5. Оформление счетов-фактур на сопровождение по авансовым остаткам с

1996 года

6. Ввод прейскурантов на сопровождение и на системы.

7. Ввод и изменение адресных и банковских реквизитов организаций.

3.2. Технические требования, предъявляемые к базе данных.

При проектировании системы автоматизации принимались во внимание

следующие требования:

- система должна нормально функционировать на стандартных персональных

компьютерах клона IBM с процессором Intel Pentium - 100 (минимальные

требования), подсоединенных к локальной офисной вычислительной сети в

режиме невыделенных серверов;

- система не должна иметь привязки к аппаратной части для возможности

переноса ее на новую платформу из-за неизбежного морального старения

компьютерной техники;

- архитектура системы должна быть выбрана таким образом, чтобы

минимизировать вероятность нарушения штатного режима работы системы (выход

системы из строя, разрушение информационной базы данных, потери или

искажение информации) при случайных или сознательных некорректных действиях

пользователей;

- система должна обеспечивать защиту информационной базы данных от

несанкционированного доступа;

- основная программная оболочка системы должна устанавливаться на

рабочие места директора и бухгалтера с любого компьютера, подсоединенного к

локальной офисной вычислительной сети;

- основная программная оболочка должна иметь интуитивно ясный

дружественный интерфейс и не должна требовать от пользователей специальной

подготовки, не связанной с их профессиональными обязанностями;

- система должна иметь возможность наращивания в программной части.

- система должна функционировать под управлением операционных систем

Windows 95 и Windows NT.

3.3. Выбор системы проектирования и реализации.

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

требований была выбрана система управления базами данных «Microsoft

Access».

Данная СУБД была выбрана по следующим причинам:

. простота средств реализации,

. легкость освоения инструментарием разработчика (VBA),

. наглядность визуализации информации.

Базы данных созданные с помощью системы управления базами данных

«Microsoft Access» полностью реализую реляционную модель построения данных.

База данных «Microsoft Access» представляет собой набор групп объектов,

таких как таблицы, запросы, формы, отчеты.

Связи между таблицами можно разбить на четыре базовых реляционных типа

с отношениями:

. один-к-одному;

. один–ко-многим;

. многие-к-одному;

. многие-ко-многим.

Структура организации таблиц позволяет создание первичных и внешних

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

связанных таблиц.

Также «Microsoft Access» предоставляет большое количество внутренних

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

. загрузка модулей по требованию;

. оптимизация дерева вызовов;

. использование файлов MDE;

. автоматическая поддержка компилированного состояния;

. использование библиотек Windows API;

. индивидуальная настройка системы;

. эффективное использование индексов;

. встроенный оптимизатор запросов.

Применение пакета «Microsoft ADT» (расширенные средства разработчика)

вводит новый уровень визуализации данных, засчет таких элементов, как «Tree

View», «Tab Control» и других.

На начальном этапе реализации база данных проектировалась на СУБД

«Microsoft Access 2.0».В дальнейшем с появлением новой версии «Microsoft

Access 7.0» база данных была переведена на новую версию СУБД, так как в

новой версии появились новые инструменты разработчика, улучшенный интерфейс

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

связанные с несовместимостью программного кода различных версий, и так как

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

возникновение проблем с совместимостью кода.

3.4. Проектирование структуры данных.

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

структура взаимодействия отделов предприятия и составлены несколько

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

типам выполняемых работ. При анализе бизнес-планов учитывались критические

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

Также был произведен анализ типов отчетности по каждому из этапов бизнес-

планов.

Данные для технической реализации проекта данные имеют следующую

структуру, проиллюстрированную Схемой 2 (основные связи).

Основной является таблица с данными по организациям («Заказчики»), к

ней отношениями один ко многим связанны таблицы с информацией по основным

(«ОсновныеСчета») и дополнительным («ДругиеСчета») счетам (у одной

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

деятельности предприятия, так и по дополнительным направлениям), к таблицам

по счетам отношением один ко многим связанны таблицы с информацией по

заказам, входящим в данный счет (в один счет может входить несколько

заказов). С другой стороны, к таблицам с данными по организациям отношением

один-ко-многим связана таблица с данными по авансовому отчету.

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

средств поступивших по авансовым платежам, что составляет основную долю

прихода денежных средств. Структура данных по авансовым платежам построена

с учетом того, что выборка по этим данным должна быть представлена в

наиболее полном виде, и как можно в более короткое время. Более того,

данная структура одинаково хорошо работает с обыкновенной схемой учета

денежных средств, то есть списание денежных средств на реализацию без учета

аванса.

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

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

такие как код номера счета, тип системы по позиции счета, количество

месяцев сопровождения системы по позиции счета, информация о типе платежа

(наличный или безналичный расчет).

В подчиненной таблице расписаны суммы авансовых платежей по месяцам.

Таким образом, данная структура реализует быстрые выборки по авансовым

задолжностям по конкретной организации, что имеет существенное значение при

оценке эффективности деятельности предприятия и прогнозирования дальнейшей

работы.

Политика расположения данных имеет критическое значение для приложения

применительно к скорости работы. Данные, которые меняются нечасто или не

меняются вовсе, названия систем семейства Консультант +, названия месяцев

года и так далее, были вынесены локально в клиентские модули, так как

скорость выборки данных с локального диска компьютера в несколько раз

больше скорости выборки данных по запросу из базы данных расположенной на

сетевом диске.

Примечание: Для связывания таблиц в дальнейшем рекомендуется, где

возможно, применять поле с уникальным значением, но не поле счетчика (так

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

значение счетчика и теряются связанные данные в подчиненных таблицах)

После реализации основной части проекта база данных была разделена на

три отдельных модуля:

. модуль для бухгалтерии (MdlByx.mdb),

. модуль для отдела сопровождения (MdlClnt.mdb),

. модуль данных (Data.mdb).

Организованная структура данных позволяет:

. организовать клиент - серверную модель данных,

. разработку и изменение модулей параллельно с работой ранее

сконструированных,

. уменьшает размер резервного файла,

В процессе технической реализации данных задач появились дополнительные

задачи:

1. Изменение данных по авансовому отчету (корректировка распределения

сумм по месяцам для организаций).

2. Общая результирующая информация по организациям, адресные и

банковские реквизиты, счета, выписанные на организации, информация по

системам для данной организации.

3. Обмен сообщениями между пользователями (использование для заказа

счетов актов и так далее).

3.4.1. Описание структуры данных проекта.

В процессе разработки базы данных была выработана следующая

иерархическая структура данных.

Часть 1. (листинг 2.1)

(таблицы «Заказчики», «СтатусЗаказчика»,«Курьеры»,«Примечания»,)

1. Связь таблицы «Заказчики» с таблицей «СтатусЗаказчика».

Поле: «Код» в обеих таблицах

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

(один со стороны таблицы «СтатусЗаказчика»)

Связывание: мастер подстановок в таблице «Заказчики»

Примечания: данная связь заменяет повторяющееся текстовые значения

типа организации соответствующим кодом из таблицы «СтатусЗаказчика».

2.Связь таблицы «Заказчики» с таблицей «Курьеры».

Поле: «КодКурьера» в обеих таблицах.

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

(один со стороны таблицы «Курьеры»)

Связывание: мастер подстановок в таблице «Заказчики»

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

«Курьеры».

3.Связь таблицы «Заказчики» с таблицей «Примечания».

Поле: «КодЗаказчика» в обеих таблицах.

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

(один со стороны таблицы «Заказчики»)

(возможно связывание один к одному)

Связывание: мастер подстановок в таблице «Примечания»

Часть 2. (листинг 2.2)

(таблицы «Заказчики», «КредитАванс», «ОсновныеСчета», «Дистрибутивы»,

«Системы»,

«ФормаОплаты», «ТипСистемы», «Платежки», «СчетаФактуры»,

«СчетаФактурыОсновные»)

1.Связь таблицы «Заказчики» с таблицей «ОсновныеСчета».

Поле: «КодЗаказчика» в обеих таблицах.

Тип связи: один ко многим с обеспечением целостности данных с каскадным

удалением и каскадным обновлением данных.

(один со стороны таблицы «Заказчики»)

Связывание: мастер подстановок в таблице «ОсновныеСчета»

Примечания: у каждого заказчика может быть много счетов.

2.Связь таблицы «Заказчики» с таблицей «КредитАванс».

Поле: «КодЗаказчика» в обеих таблицах.

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

(один со стороны таблицы «Заказчики»)

(возможно связывание один к одному?)

Связывание: мастер подстановок в таблице «КредитАванс»

3.Связь таблицы «Заказчики» с таблицей «СчетаФактуры».

Поле: «КодЗаказчика» в обеих таблицах.

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

(один со стороны таблицы «Заказчики»)

Связывание: мастер подстановок в таблице «СчетаФактуры»

Примечания: у каждого заказчика может быть много счетов-фактур.

4. Связь таблицы «ОсновныеСчета» с таблицей «Дистрибутивы».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим с обеспечением целостности данных с каскадным

удалением и каскадным обновлением данных.

(один со стороны таблицы «ОсновныеСчета»)

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

Примечания: в каждый счет может входить много записей по заказам.

5. Связь таблицы «ОсновныеСчета» с таблицей «Платежки».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим с обеспечением целостности данных с каскадным

удалением и каскадным обновлением данных.

(один со стороны таблицы «ОсновныеСчета»)

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

Примечания: в каждому счету может относится несколько платежных

поручений.

(*Если платежное поручение оплачивает несколько счетов, то при внесении

данных к счетам пишется одно и тоже платежное поручение, но суммы вносятся

в соответствии с суммой счета)

6. Связь таблицы «ОсновныеСчета» с таблицей «СчетаФактурыОсновные».

Поле: «КодСчета» в обеих таблицах.

Тип связи: один ко многим с обеспечением целостности данных с каскадным

удалением и каскадным обновлением данных.

(один со стороны таблицы «ОсновныеСчета»)

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

Примечания: в каждому счету может относится несколько счетов-фактур на

системы.

7. Связь таблицы «Дистрибутивы» с таблицей «Системы».

Поле: «КодСистемы».

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

(один со стороны таблицы «Системы»)

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

Примечания: данная связь заменяет повторяющееся текстовые значения

названия систем соответствующим кодом из таблицы «Системы».

8. Связь таблицы «Дистрибутивы» с таблицей «ТипСистемы».

Поле: «Код» в обеих таблицах.

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

(один со стороны таблицы «ТипСистемы»)

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

Примечания: данная связь заменяет повторяющееся текстовые значения типа

систем соответствующим кодом из таблицы «ТипСистемы».

9. Связь таблицы «ОсновныеСчета» с таблицей «ФормаОплаты».

Поле: «Код» в обеих таблицах.

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

(один со стороны таблицы «ФормаОплаты»)

Связывание: мастер подстановок в таблице «ОсновныеСчета»

Примечания: данная связь заменяет повторяющееся текстовые значения

формы оплаты счета соответствующим кодом из таблицы «ФормаОплаты».

10. Связь таблицы «Системы» с таблицей «КредитАванс».

Временная связь, возможно в дальнейшем будет удалена.

Часть 3. (листинг 2.3)

(таблицы «Заказчики», «ОсновныеСчета», "АвансПоОстаткамС1996Года»,

«ДанныеДляАвансОтчета», «Системы», «АвансовыйОтчет».)

1. Связь таблицы «Заказчики» с таблицей «АвансПоОстаткамС1996Года».

Поле: «КодЗаказчика» в таблице «Заказчики» с полем «Заказчик» в таблице

«АвансПоОстаткамС1996Года».

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

(один со стороны таблицы «Заказчики»)

Связывание: в окне схемы данных.

Примечания: к каждому заказчику может относится несколько записей по

месяцам по авансовому отчету.

2. Связь таблицы «Заказчики» с таблицей «ДанныеДляАвансОтчета».

Поле: «КодЗаказчика» в обеих таблицах.

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

(один со стороны таблицы «Заказчики»)

Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчета»

Примечания: для данной организации данных к каждому заказчику может

относится несколько записей по авансовому отчету.

3. Связь таблицы «Системы» с таблицей «ДанныеДляАвансОтчета».

Поле: «КодСистемы» в обеих таблицах.

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

(один со стороны таблицы «Заказчики»)

Связывание: мастер подстановок в таблице «ДанныеДляАвансОтчета»

Примечания: данная связь заменяет повторяющееся текстовые значения

названия системы соответствующим кодом из таблицы «Системы».

4. Связь таблицы «ОсновныеСчета» с таблицей «ДанныеДляАвансОтчета».

Поле: «КодСчета» в обеих таблицах.

Страницы: 1, 2, 3, 4, 5, 6