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 (минимальные требования), подсоединенных к локальной офисной вычислительной сети в режиме невыделенных серверов;
- система не должна иметь привязки к аппаратной части для возможности переноса ее на новую платформу из-за неизбежного морального старения компьютерной техники;
- архитектура системы должна быть выбрана таким образом, чтобы минимизировать вероятность нарушения штатного режима работы системы (выход системы из строя, разрушение информационной базы данных, потери или искажение информации) при случайных или сознательных некорректных действиях пользователей;
- система должна обеспечивать защиту информационной базы данных от несанкционированного доступа;
Страницы: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18
