1 ПРОЕКТИРОВАНИЕ ИНФОРМАЦИОННОЙ СИСТЕМЫ
Информационная система состоит (в узком смысле) из прикладных программ, СУБД и базы данных. На бытовом уровне всю информационную систему называют базой данных. Такая подмена терминов пользователям информационных систем удобна, потому что, во-первых, короче, а во-вторых, данные извлекаются из базы, а как это делается, какие программы при этом работают, пользователя не интересует. Замечено, что неопытный проектировщик (например, студент, делающий курсовую работу) интуитивно также воспринимает информационную систему, прежде всего, как базу данных и начинает проектирование с разработки структуры базы данных без тщательной проработки постановки задачи.
Структура базы данных очень сильно зависит не только от объекта (завода, банка, вуза, цеха), для которого она строится, но и от задач, которые с её помощью будут решаться. Например, в базе данных вуза, созданной для отдела кадров, нет необходимости хранить данные об успеваемости студентов, а в базе учебного отдела не нужны данные об уборщицах. Создание базы данных до детальной постановки задачи приводит к тому, что в базе будет отсутствовать часть необходимых для работы информационной системы данных, и, в то же время, будут храниться избыточные данные.
Информационные системы относятся к классу сложных систем. Точного определения понятия сложная система нет и в первом приближении нужно понимать его буквально как система, состоящая (сложенная) из нескольких подсистем. Описать сложную систему в целом, в силу её сложности можно только в общих чертах. Для детального исследования сложную систему делят на подсистемы и исследуют взаимодействие подсистем между собой, а также каждую подсистему в отдельности. При проектировании сложных систем возможны два подхода: сверху вниз и снизу-вверх.
При проектировании сверху вниз сначала формулируют критерии выбора оптимальной системы в целом, а затем разбивают систему на подсистемы и на основании общих критериев формулируют критерии проектирования каждой подсистемы. Недостаток этого подхода в том, что общий критерий формулируется при недостаточном знании подсистем и может оказаться невыполнимым.
При проектировании снизу-вверх система сразу разбивается на подсистемы и для каждой подсистемы формулируют свой критерий, а затем на основании частных критериев формулируют общий критерий для всей системы. Принципиальный недостаток этого подхода в несовпадении интересов подсистемы и системы. Например, механическому цеху выгодно обрабатывать как можно большие партии деталей, а заводу нужно обеспечить ритмичную сборку для выпуска как можно большего количества готовой продукции. Для этого детали из механического цеха должны поступать строго по графику в строго заданных, может быть и маленьких, количествах.
На практике из-за описанных недостатков редко применяют только один из описанных подходов. Процесс проектирования системы обычно состоит из множества итераций. На каждой итерации с учётом полученных на предыдущих итерациях результатов применяется то подход сверху вниз, то снизу-вверх. И так до тех пор,
