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

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

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

1. в конторском деле - для замены секретарей-машинисток и делопроизводителей;

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



2.2.4 Технические средства, используемые во внутрифирменной системе информации

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

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

Современные ЭВМ способны одновременно обрабатывать цифровую, текстовую и графическую информацию.

В процессе автоматизации управления мини-ЭВМ используются, преимущественно, для:

- разработки оперативных планов производства и контроля за их выполнением;

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

- расчета заработной платы;

- контроля над поступлением заказов;

- анализа данных о сбыте продукции;

- регистрации поступления платежей;

- ведения учета и отчетности.

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

2.2.5 Формы как носители информации

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

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

Заполненные формы хранятся в памяти ЭВМ и при необходимости могут быть выведены на экран дисплея или получены путем распечатки на принтере. В случае необходимости размножения заполненной и хранящейся в ЭВМ формы это делается с помощью копирующего устройства той же ЭВМ.

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



2.2.6 Применение информационных баз данных

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

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

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

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

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

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

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

1. Вычислительный центр для обслуживания фирмы в целом;

2. Центральную службу информации;

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

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

1. Отдел автоматизации (отдел программирования);

2. Технический отдел (отдел сетевых разработок).

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

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



2.2.6.1 Реляционные базы данных

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

С. Дейт дает следующее неформальное определение системе управления реляционными базами данных (СУБД).

- Вся информация в базе данных представлена в виде таблиц.

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

Др. И.Ф. Кодд, автор реляционной модели, разработал целый список критериев, которым должна удовлетворять реляционная модель. Описание этого списка, часто называемого «правилами Кодда», требует введения сложной терминологии и теоретических выкладок, что выходит за рамки данного дипломного проекта. Тем не менее, опишем состоящий из 12 правил тест Кодда для реляционных систем, и будем использовать его совместно с общим определением Дейта.

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

- представлять всю информацию в виде таблиц,

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

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

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

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

- различать в таблицах неизвестные значения (nulls), нулевые значения и пропуски в данных,

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

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

2.2.6.2 Реляционная модель: одни таблицы

Первое правило Кодда гласит, что вся информация в реляционных базах данных представляется значениями в таблицах (tables). В реляционных системах таблицы состоят из горизонтальных строк (row) и вертикальных столбцов (column). Все данные представляются в табличном формате - другого способа просмотреть информацию в базе данных не существует. Несколько замечаний по терминологии. Поскольку такие понятия как таблица, строка и столбец являются общепринятыми в коммерческих системах управления реляционными базами данных, будем стараться использовать их в этом дипломном проекте. Однако иногда можно встретиться и с такими понятиями, как отношение (relations), кортеж (tuple) и атрибут (attributes). Это соответственно синонимы понятий таблица, строка и столбец, так же, как и файл (file), запись (record) и поле (field). Первые три считаются академическими терминами, последние-взяты из общего лексикона, используемого в области обработки данных. Набор связанных таблиц образует базу данных (database). Таблицы в реляционной базе разделены, но полностью равноправны. Между ними не существует никакой иерархии и, вообще говоря, они не обязательно даже физически связаны друг с другом.

Каждая таблица состоит из строк и столбцов. Каждая строка описывает отдельный объект или сущность (entity) человека, компанию, торговую сделку или что-нибудь другое. Каждый столбец описывает одну характеристику объекта - имя человека или его адрес, телефонный номер компании или ее президента, лоты распродажи или дату. Каждый элемент данных, или значение (value), определяется пересечением строки и столбца таблицы. Чтобы найти требуемый элемент данных, необходимо знать имя содержащей его таблицы, столбец и значение его первичного ключа (primary key), или уникального идентификатора (каждая строка должна единственным образом идентифицироваться по одному из своих значений.)

В реляционных базах данных существует два типа таблиц - пользовательские таблицы (user tables) и системные таблицы (system tables). Пользовательские таблицы содержат информацию, для поддержки которой собственно и создавались системы реляционных баз данных - данные по сделкам, заказам, персоналу и т.д. Системные таблицы, известные также под названием системные каталоги (system catalog), содержат описание базы данных. Системные таблицы обычно поддерживаются самой СУБД, однако доступ к ним можно получить так же, как и к любым другим таблицам. Возможность получения доступа к системным таблицам, по аналогии с любыми другими таблицами, составляет основу другого правила Кодда для реляционных систем.

2.2.6.3 Независимость

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

Реляционная модель обеспечивает независимость данных на двух уровнях - физическом и логическом. Физическая независимость данных (physical data independents) означает с точки зрения пользователя, что представление данных абсолютно не зависит от способа их физического хранения. Как следствие этого, физическое перемещение данных никоим образом не может повлиять на логическую структуру базы данных и ваше восприятие данных. Такие изменения обычно становятся просто необходимыми, особенно в больших многопользовательских системах. Например, при недостатке места для хранения информации может потребоваться установка дополнительных физических носителей. Когда устройство выходит из строя, - увы, его приходится быстро заменять. Иногда может потребоваться увеличить производительность системы или упростить ее использование, изменив для этого методы доступа к физическим данным. (Эти методы связаны с созданием стратегии доступа (access strategies) и применением индексов (index).)

Другой тип независимости, обеспечиваемый реляционными системами - логическая независимость (logical independents) означает, что изменение взаимосвязей между таблицами, столбцами и строками не влияет на правильное функционирование программных приложений и текущих запросов. Можно разбивать таблицы по строкам или столбцам, а приложения и запросы все равно будут выполняться, как и раньше. Несмотря на изменение логической структуры базы данных, всегда можно воспользоваться старыми запросами. Требование логической и физической независимости данных составляет основу двух других правил Кодда.



2.2.6.4 Язык высокого уровня

Определение реляционной системы, так же, как и правила Кодда, требует, чтобы весь диалог с базой данных велся на едином языке - иногда его называют общим подъязыком данных (comprehensive data sublanguage). В мире коммерческих систем управления базами данных такой язык получил название SQL. SQL используется для манипуляций с данными (data manipulation) выборки и модификации, определения данных (data definition) и администрирования данных (data administration). Любая операция по выборке, модификации, определению или администрированию выполняется с помощью оператора (statement) или команды (command) SQL.

Имеется две разновидности операций по манипуляции с данными - выборка данных (data retrieval) и модификация данных (data modification). Выборка - это поиск необходимых вам данных, а модификация означает добавление, удаление или изменение данных. Операции по выборке (чаше называемые запросами (query)) осуществляют поиск в базе данных, наиболее эффективно извлекают затребованную вами информацию и отображают ее. Другие команды SQL предназначены для создания и удаления таблиц, индексов и других объектов.

Последняя категория операторов SQL-операторы администрирования, или команды управления данными (data control). Они позволяют вам координировать совместное использование базы данных и поддерживать ее в наиболее эффективном состоянии.

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

2.2.6.5 Реляционные операции

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

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

2.2.6.6 Проектирование

Операция проектирования позволяет указать системе, какие столбцы таблицы должны просматриваться. С концептуальной точки зрения: операция проектирования определяет подмножество столбцов в таблице. Обратите внимание, что результаты выполнения проектирования (как и любой другой реляционной операции) также отображаются в форме таблицы. Результирующие таблицы иногда называют производными таблицами (derived tables), чтобы отличать их от базовых таблиц (base tables), содержащих исходные строки данных.

Выбор. Операция выбора позволяет вам получать из таблицы подмножества ее строк. Чтобы указать, какие строки нужны, соответствующие условия нужно разместить в предложении WHERE. В предложении WHERE оператора SELECT определяется критерий, которому должны соответствовать выбираемые строки. Можно комбинировать в запросе операции проектирования и выбора, чтобы получить требуемую информацию.

2.2.6.7 Объединение

Операция объединения может работать одновременно с одной или несколькими таблицами, соединяя данные таким образом, что можно легко сопоставить или выделить определенную информацию в базе данных. Операция объединения обеспечивает SQL и реляционную модель необходимой мощностью и гибкостью. Можно выявить любую взаимосвязь, существующую между элементами данных, а не только связи, введенные при конструировании базы. Когда «объединяются» две таблицы, на период действия запроса они как бы становятся единой таблицей. Операция объединения соединяет данные, сравнивая значения в заданных столбцах и отражая результаты.

2.2.6.8 Альтернативный способ просмотра данных

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

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

2.2.6.9 Нули

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

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

С точки зрения другого эксперта по реляционным системам, Дейта, нули не являются полноценным решением проблемы пропусков информации. Тем не менее, они являются составной частью большинства официальных стандартов SQL и de facto промышленных стандартов.

2.2.6.10 Безопасность

Понятие безопасности связано с необходимостью управления доступом к информации. Определенные команды позволяют некоторым привилегированным пользователям устанавливать права других пользователей на просмотр и модификацию информации в базе данных. В большинстве реализаций реляционных баз данных правами на доступ и модификацию данных (permission) можно управлять на уровне таблиц и столбцов. Эти права устанавливают владельцы (owner) баз данных или объектов баз данных. Некоторые системы разрешают передавать права владения от создателя базы другому пользователю.

В многопользовательских системах обычно имеется пользователь с правами даже более высокими, чем у владельца базы данных-системный администратор (system administrator), или администратор базы данных (database administrator). Этот пользователь обычно обладает широкими правами на наделение полномочий, а также выполняет целый ряд других задач, связанных с поддержкой и администрированием базы данных.

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

2.2.6.11 Целостность

Целостность (integrity) - очень сложный и серьезный вопрос при управлении реляционными базами данных. Несогласованность между данными может возникать по целому ряду причин. Несогласованность или противоречивость данных может возникать вследствие сбоя системы-проблемы с аппаратным обеспечением, ошибки в программном обеспечении или логические ошибки в приложениях. Реляционные системы управления базами данных защищают данные от такого типа несогласованности, гарантируя, что команда либо будет исполнена до конца, либо будет полностью отменена. Этот процесс обычно называют управлением транзакциями (transaction management).

Другой тип целостности, называемый объектной целостностью (entity integrity), связан с корректным проектированием базы данных. Объектная целостность требует, чтобы ни один первичный ключ не имел нулевого значения. Третий тип целостности, называемый ссылочной целостностью (referential integrity), означает непротиворечивость между частями информации, повторяющимися в разных таблицах. Например, если вы изменяете неправильно введенный номер расчетного счета покупателя в одной таблице, другие таблицы, содержащие эту же информацию, продолжают ссылаться на старый номер, поэтому вы должны обновить и эти таблицы. Чрезвычайно важно, чтобы при изменении информации в одном месте, она соответственно изменялась и во всех других местах. Правила Кодда гласят, что системы управления реляционными базами данных должны обеспечивать не только объектную и ссылочную целостность, но и позволять «вводить дополнительные ограничения на целостность, отражающие специальные требования». Кроме того, по определению Кодда, ограничения на целостность должны:

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

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

Первоначально только несколько реализаций реляционных баз данных удовлетворяли критериям Кодда на целостность, но ситуация постепенно изменялась. Стандарт 1992 года (часто называемый «SQL92») поддерживает ограничения, обеспечивающие ссылочную целостность и позволяющие задавать бизнес правила. Эти возможности в том или ином виде реализованы в большинстве систем.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

3. В ходе работы обязательно должен создаваться макет таблиц и связей между ними, называемый структурой данных (data structure), или диаграммой зависимостей между объектами (E-R diagram).

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

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

Имеются ли зависимости типа один-ко-многим (один заказчик может иметь множество выписанных счетов, но каждый счет может быть выписан только на одного заказчика) или многие-ко-многим?

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

5. Анализ структуры базы данных с точки зрения правил нормализации для поиска логических ошибок. Исправление всех отклонений от нормальных форм или обоснование решения отказаться от выполнения ряда правил нормализации в интересах простоты освоения или производительности. Документирование причины таких решений.

6. Непосредственному создание структуры базы данных и помещению в нее некоторых прототипов данных. Обязательное экспериментирование с запросами, изучение полученных результатов. Выполнение рядов тестов на производительность, чтобы проверить разные технические решения.

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

2.2.6.14 Структура базы данных

Что такое «хорошая структура»? Хорошая структура - это, в первую очередь, «прозрачная» структура. Проще говоря, хорошая структура - это:

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

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

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

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

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

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

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

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

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

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

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

2.2.6.15 Нормализация

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- система должна нормально функционировать на стандартных персональных компьютерах клона IBM с процессором Intel не менее 300MHz, 64MB RAM (минимальные требования;

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

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

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

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

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

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

Для нормального функционирования может использоваться практически любая современная СУБД. Единственным требованием является наличие поддержки интерфейса ODBC. В качестве базы данных наиболее оптимальной, с точки зрения производительности, отказоустойчивости и безопасности, является Oracle, но эта база требует выделенного высокопроизводительного сервера, что в условиях данного предприятия является неприемлемым.

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

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

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

- отсутствие необходимости в выделенном сервере,

- приемлемая скорость обработки транзакций.

В качестве среды разработки была выбрана платформа Borland C++ Builder v.5.0. Одним из достоинств этой среды является возможность «быстрой» разработки приложений - RAD (Rapid Application Development). Большим плюсом является возможность генерировать код, независящий от установленных компонент. Таким образом не требуется устанавливать никаких дополнительных компонент, за исключением клиентской части сервера базы данных для функционирования ODBC или же просто ODBC драйверов для выбранной СУБД. ODBC позволяет использовать транзакции, что сохраняет целостность базы и ведет к общему ускорению как клиентской программы, так и сервера базы данных. Также имеется возможность разрабатывать приложения клиент-сервер.

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

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

2.3.3 Структура базы данных

Созданная база данных имеет следующую структуру:

Рисунок 1



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

2.3.4 Использование программы

Ниже приведены экранные снимки с описаниями возможностей программы.

Рисунок 2

Главное меню «Кадры» (рисунок 2) предоставляет доступ к приложениям «Личные карточки», «Табеля», «Журналы регистрации». Ввод , корректировка, просмотр и поиск.

Приложения «Журналы» содержит три журнала регистрации: трудовых книжек, командировок, больничных листов.



Рисунок 3

Приложение «Личные карточки» представляет собой электронную версию личной карточки, которую заполняет каждый вновь прибывший.

Его меню представляет собой список личных карточек сотрудников, позволяющий редактировать каждую карточку индивидуально. Редактирование - кнопка Edit, заполнение новой - кнопка New.

Рисунок 4



Приложение «Личные карточки». Раздел «Общие сведения»

Соответствует разделу «Общие сведения» личной карточки. Поля «Дата» являются выпадающими (Рисунок 5).

Рисунок 5

Возможна корректировка поля «Дата» по году, месяцу, числу.

Для изменения значения года необходимо щелкнуть на цифру года и откорректировать ее при помощи появившихся стрелок «вверх/вниз».

Для изменения значения месяца используются стрелочки «влево/вправо», расположенные соответственно посторона названия месяца.

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



Рисунок 6

Поля «Родной язык» и «Гражданство» - выпадающие списки, которые являются самозаполняющимися (при занесении новых значений, список атоматически адаптируется). В то время как список «Семейное положение» является фиксированным (значение выбирается из фиксированных ариантов).

Рисунок 7



Нажатие кнопок New/Edit вызывает окно «Семья» с выпадающими датами. Предназначенное для занесения сведений о членах семьи. Поле «Должность» является самозаполняющися справочником.

Рисунок 8

Приложение «Личные карточки». Раздел «Воинский учет»

Соответствует разделу личной карточки «Воинский учет».

Рисунок 9



Приложение «Личные карточки». Раздел «Образование и ПК»

Соответствует разделам личной карточки «Образование» и «Повышение квалификации»

Рисунок 10

Нажатие кнопок New/Edit вызывает окно «Повышение квалификации». Предназначенное для заполнения данных о повышениях квалификации.

Рисунок 11



Приложение «Личные карточки». Раздел «Профессия и перемещения»

Соответствует раздела личной карточки «Профессия» и «Назначения и перемещения». Выпадающие поля «Должность» и «Подразделение» являются самозаполняющимися спрвочниками.

Рисунок 12

Нажатие кнопок New/Edit вызывает окно «Назначения и перемещения» с выпадающими датами. Предназначенное для заполнеия сведений о назначениях и перемещениях.



Рисунок 13

Приложение «Личные карточки». Раздел «Отпуска»

Соответствует разделу личной карточки «Отпуска».

Рисунок 14

Нажатие кнопок New/Edit вызывает окно «Отпуска», предназначенное для занесения сведений об отпусках, с автоматическим просчетом общего количества дней и даты окончания. Поля «Дата» - выпадающие.



Рисунок 15

Приложение «Личные карточки». Раздел «Дополнительно»

Соответствует разделу личной карточки «Дополнительно», а также содержит информацию о приеме на работу и увольнении.

Рисунок 16



Приложение «Табеля»

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

Рисунок 17

Нажатие кнопок New/Edit вызывает окно «Табель» . В нем заносятся данные в поля «»Номер» , «Месяц», «Год» и «Табельный номер» и информация по отработанному времени. Поле «ФИО» заполняется автоматически , после внесения информации в поле «Табельный номер».

Рисунок 18



Приложение «Журнал регистрации трудовых книг»

Нажатие кнопок New/Edit вызывает окно «Регистрация трудовой книги».

Рисунок 19

Поле «ФИО» заполняется атоматически, после заполнения поля «Табельный номер».

Поля «дата» - выпадающие

Рисунок 20



Приложение «Журнал регистрации командировок»

Нажатие кнопок New/Edit вызывает окно «Регистрация командировок».

Рисунок 21

Поле «ФИО» заполняется атоматически, после заполнения поля «Табельный номер».

Поля «дата» - выпадающие

Рисунок 22



Приложение «Журнал регистрации больничных»

Нажатие кнопок New/Edit вызывает окно «Регистрация больничных».

Рисунок 23

Поле «ФИО» заполняется автоматически, после заполнения поля «Табельный номер».

Поля «дата» - выпадающие

3 Организационно-экономическая часть

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

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

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

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

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



3.1 План распределения работ и сроки их выполнения

Общий план разработки системы складывается из определенных этапов деятельности. Каждый вид деятельности имеет свои функции. В таблице 8 представлен состав и продолжительность требуемых работ.

Таблица 8 - График работ

Наименование работ	Длительность, дней
Изучение специфики предприятия	20
Составление и согласование ТЗ	5
Изучение специальной литературы	5
Составление дизайна и алгоритма работы программы

Подобные документы

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

  Разработка проекта программного комплекса для автоматизации информационных процессов службы сбыта пищевой продукции. Разработка информационной базы данных и характеристика процесса создания клиентской и сервисной части приложения по технологии ASP.NET.
  
  дипломная работа [2,4 M], добавлен 24.06.2011
  

• Разработка программного обеспечения "Туристическая фирма"

  Разработка программного обеспечения, предназначенного для автоматизации деятельности туристической фирмы. Анализ и проектирование базы данных предметной области. Создание концептуальной, логической и физической моделей данных и программы их обработки.
  
  курсовая работа [816,5 K], добавлен 05.02.2018
  

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

  Расчет издержек предприятия на разработку программного продукта и экономической эффективности от его внедрения. Топология физических связей и структуризация сети. Характеристика программного обеспечения. Средства автоматизации, описание алгоритма задачи.
  
  дипломная работа [867,6 K], добавлен 05.11.2015
  

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

  Анализ входной и выходной информации на предприятии. Осуществление функционального и информационного моделирования базы данных, создание ее структуры. Программная реализация системы автоматизации учета работы автотранспорта. Оценка трудоемкости проекта.
  
  дипломная работа [1,2 M], добавлен 09.07.2012
  

• Система информационного обеспечения деятельности в ООО "Эстэл-Инфо"

  Анализ системы информационного обеспечения деятельности в ООО "Эстэл-Инфо". Стратегия оптимизация автоматизации деятельности предприятия. Оценка социально-экономической эффективности проекта методической поддержки стратегии автоматизации бизнес-процессов.
  
  курсовая работа [252,8 K], добавлен 06.01.2012
  

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

  Анализ существующих систем автоматизации документооборота. Выбор шаблона проектирования. Microsoft SQL Server как комплексная высокопроизводительная платформа баз данных. Язык программирования C#. Разработка интерфейса и иллюстрация работы системы.
  
  дипломная работа [2,5 M], добавлен 19.07.2014
  

• Разработка информационного и программного обеспечения объектов автоматизации

  Методы концептуального, логического и физического проектирования баз данных для автоматизации работы объекта. Обследование предметной области; тестирование и реализация информационного и программного обеспечения. Подготовка конструкторской документации.
  
  курсовая работа [4,0 M], добавлен 16.05.2012
  

• Электронный справочник программиста на предприятии (с базой данных)

  Принципы автоматизации делопроизводства. Общие понятия документооборота. Проектирование программного обеспечения. Стадии и этапы создания информационных систем, средства их разработки. Анализ алгоритмов работы с базой данных, разработка интерфейса.
  
  дипломная работа [3,4 M], добавлен 07.11.2015
  

• Информационная система управления качеством. Создание программного обеспечения на основе библиотеки ITIL. Подсистема автоматизации процесса "Служба Service Desk"

  Простые системы для отслеживания заявок. Информационные потоки, возникающие на этапе поступления запроса для решения инцидента. Концептуальная и логическая модель данных. Разработка программного обеспечения по автоматизации процесса Службы Service Desk.
  
  дипломная работа [2,6 M], добавлен 11.06.2017
  

• Задачи автоматизации, хранения и обработки информации на предприятии

  Системы управления базами данных и их использование для решения задач автоматизации предприятия. Разработка информационного и программного обеспечения для автоматизации хранения и обработки информации при организации работы агропромышленного предприятия.
  
  курсовая работа [607,1 K], добавлен 07.05.2011
  

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