Дипломная работа: Проектирование, разработка и внедрение БД ИС в экономическую деятельность предприятия (на примере ГП "Алушталифт")

Дипломная работа

Проектирование, разработка и внедрение БД ИС в экономическую деятельность предприятия (на примере ГП "Алушталифт")

По специальности "Экономическая кибернетика"

Симферополь, 2010

Содержание

Введение

1. Теоретико-методические основы проектирования, разработки и внедрения БД ИС в экономическую деятельность предприятия

1.1 Общая характеристика баз данных и информационных систем

1.2 Теория реляционных баз данных

1.3 Методы проектирования БД ИС

Выводы по Разделу 1

2. Анализ и оценка финансового состояния ГП "АЛУШТАЛИФТ"

2.1 Организационная характеристика предприятия

2.2 Экономическая характеристика предприятия, финансовый анализ и оценочные показатели

Выводы по Разделу 2

3. Разработка и проектирование БД ИС на предприятии ГП "АЛУШТАЛИФТ"

3.1 Проектирование БД ИС "Вызов"

3.2 Разработка БД ИС "Вызов" в среде Delphi 7

3.3 Внедрение БД ИС "Вызов" и оценка эффективности

Выводы по Разделу 3

Заключение

Список использованных источников

Введение

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

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

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

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

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

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

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

Исходя из поставленной цели вытекают следующие задачи:

изучить теоретические основы проектирования, разработки и внедрения БД ИС в экономическую деятельность предприятия;

проанализировать финансовое состояние предприятия;

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

реализовать полученную физическую модель БД ИС "Вызов" в среде Delphi;

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

Объектом данного исследования является Государственное предприятие "Алушталифт". Предметом исследования данной работы является комплекс экономических показателей, направленных на определение существующего финансового состояния предприятия и последующего внедрения БД ИС в деятельность предприятия.

1. Теоретико-методические основы проектирования, разработки и внедрения БД ИС в экономическую деятельность предприятия

1.1 Общая характеристика баз данных и информационных систем

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

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

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

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

Прежде чем перейти к обсуждению понятия информационной системы (ИС), попытаемся выяснить, что же понимается под словом информация. Информация (от лат.informatio— осведомление, разъяснение, изложение, от лат.informare— придавать форму)— в широком смысле абстрактное понятие, имеющее множество значений, в зависимости от контекста. В узком смысле этого слова— сведения (сообщения) независимо от формы их представления. (Стратонович Р. Л. Теория информации. М.: Сов. радио, 1975).

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

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

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

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

Воройский Ф.С определяет: информацию как данные, которым придается некоторый смысл (интерпретация) в конкретной ситуации в рамках некоторой системы понятий. Информация представляется посредством кодирования данных и извлекается путем их декодирования и интерпретации [8, С. 10-11].

В этом определении фиксируется три основных преобразования информации и данных в процессе их обработки в ИС: информация-данные, данные-данные, данные-информация.

На рис. 1.1 представлены две стороны определения понятия информации: функциональная и представительная. Первая в общих чертах определяет круг действий над информацией, а вторая - результат выполнения этих действий [8, С. 12].

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

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

Рис. 1.1. Содержание термина "информация" по [8]

Рассмотрим различные определения информационных систем:

Под информационной системой (ИС) понимается организационная совокупность технических и обеспечивающих средств, технологических процессов и кадров, реализующих функции сбора, обработки, хранения, поиска, выдачи и передачи информации. (Вендров А.М. Проектирование программного обеспечения экономических информационных систем. - М.: Финансы и статистика. 2000.)

По определению Закона Украины "Об информации, информатизации и защите информации" от 25 января 1995 года, информационная система (ИС), в широком смысле своего значения, есть "организационно упорядоченная совокупность документов (массивов документов) и информационных технологий, в том числе с использованием средств вычислительной техники и связи, реализующих информационные процессы". Так же юридическое определение термина "информационная система", как "автоматизированная система, компьютерная сеть или система связи", дано в ("Положении о технической защите информации в Украине", утвержденному Указом Президента Украины от 27.09.99 г. № 1229/99).

Необходимость повышения производительности труда в сфере информационной деятельности приводит к тому, что в качестве внешних средств хранения и быстрого доступа к информации чаще всего используются средства вычислительной техники (цифровой и аналоговой) на основе компьютеров. Современные ИС - сложные комплексы аппаратных и программных средств, технологии и персонала, которые еще называют автоматизированными информационными системами. Структурно ИС включают в себя аппаратное (hardware), программное (software), коммуникационное (netware), промежуточного слоя (middleware), лингвистическое и организационно-технологическое обеспечение.

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

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

Программное обеспечение ИС обеспечивает реализацию функций ввода данных, их размещения на машиночитаемых носителях, модификации данных, доступ к данным, поддержку функционирования оборудования. Программное обеспечение можно разделить на системное (которое венчает процесс выбора аппаратно-программного решения, или платформы, как говорят в настоящее время) и пользовательское (которое применяется для решения задач удовлетворения потребностей пользователя в компьютерной среде, а именно, реализует бизнес-логику) [8, С. 18]

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

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

На рис. 1.2 просуммированы в общих чертах функции ИС через ее основные структурные компоненты. [14. С.85]

Рис. 1.2. Определение информационной системы по [14]

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

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

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

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

Разработчики ИС фактически всегда находятся в методике "из-середины" (midlle of design). Есть некоторая основа (уже созданная или создаваемая), и вокруг нее следует развиваться в различных направлениях, не сильно ломая сложившиеся традиции. Таким образом, постулируется итерационный подход в разработке и создании информационных систем. И, как следует из вышесказанного, он определяется не желанием теоретиков ИС, а жизненной необходимостью [14, С 89-90]

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

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

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

Для того чтобы ИС жила долго и ее эксплуатация приносила ощутимую выгоду, необходимо тщательно проектировать и ее архитектуру, и ее составные компоненты, в частности базы данных, о которых пойдет речь ниже. Подавляющее большинство компьютеров, которые используются для аппаратного обеспечения создателями ИС, являются компьютерами фон Неймана. Основная идея, положенная в основу создания компьютера фон Неймана, состоит в том, что компьютер представляет собой вычислительную машину с загружаемым в его память кодом - программами и данными. В процессе своей работы такая машина интерпретирует код и различает программы (исполняемый код) и данные (неисполняемый код). Рассмотрим основные подходы к обработке информации в автоматизированных информационных системах. Одним из главных вопросов разработки программного обеспечения ИС (и программирования как самостоятельной дисциплины) является вопрос о соотнесении программ и данных, ибо решение этого вопроса, в конечном счете, определяет выбор алгоритмов обработки информации, аппаратных средств и технологической платформы. Фундаментальным принципом в решении вопроса о соотнесении программ и данных является концепция независимости прикладных программ от данных, и неважно, какая обработка данных предполагается: централизованная или распределенная. Суть этой концепции состоит не столько в отделении программ от данных, сколько в рассмотрении их как самостоятельных взаимодействующих объектов [14, С. 105] Одной из последних модификаций этого принципа является концепция независимости прикладных программ от данных вместе с процедурами их обработки (объектно-ориентированный подход в программировании), который позволяет решить ряд вопросов обработки данных, связанных с интерпретацией семантического смысла данных. Торжество концепции независимости программ от данных привело к формированию в 1962 году концепции базы данных (БД) и созданию на ее основе метода баз данных для решения задач обработки информации. До середины 60-х годов прошлого века основной концепцией построения программного обеспечения являлась концепция файловой системы и так называемый позадачный метод. Такой подход по-прежнему остается доминирующим в разработке и функционировании несущих операционных платформ. В конце 80-х годов прошлого века была предложена концепция объектно-ориентированных баз данных и объектно-ориентированный подход разработки программ на основе обработки событий [21, С. 68]. На рис. 1.4 представлены основные черты для каждой из указанных выше концепций. На рис. 1.3 проведено сопоставление основных методов обработки данных: концепции файловой системы, концепция баз данных и концепция объектно-ориентированных баз данных. Основной смысл объектной технологии состоит в том, что программы рассматриваются как совокупность объектов. Объекту присущи следующие свойства:

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

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

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

Рис. 1.3. Основные методы обработки информации по [21]

Рис. 1.4. Основные концепции обработки информации по [21]

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

Базу данных в общем случае можно определить как унифицированную совокупность хранимых и воспроизводимых данных, используемых в рамках организации (Engles R.A., 1972 г.). Однако понятие базы данных не основывается в настоящее время на единой концепции, скорее это целое семейство связанных между собой понятий из предметной области, программного и аппаратного обеспечения, анализа и моделирования данных и приложений. Мы дадим несколько определений базы данных.

Рассмотрим различные определения баз данных

База данных есть совокупность взаимосвязанных данных, совместно используемых несколькими приложениями и хранящимися с (минимальной) регулируемой избыточностью. Данные запоминаются таким образом, чтобы они, по мере возможности, не зависели от программ. Для обработки данных применяется общий управляющий метод доступа. Если базы данных не пересекаются по структуре, то говорят о системе баз данных [21, С. 75].

(Согласно материалам комитета КОДАСИЛ) База данных состоит из всех экземпляров записей, экземпляров наборов записей и областей, которые контролируются конкретной схемой. (Под схемой можно понимать карту всей логической структуры базы данных. Определение понятия схемы по КОДАСИЛ будет дано при обсуждении сетевой модели данных) [20, С. 83].

Законодательством Украины, термин БАЗА ДАННЫХ определяется как "совокупность произведений, данных или какой-либо иной независимой информации в произвольной форме, в том числе электронной, подбор и расположение составных частей которой и ее упорядочение является результатом творческого труда, составные части которой доступны индивидуально и могут быть обнаружены при помощи специальной поисковой системы на основании электронных средств (компьютера) или иных средств" (Закон Украины "О распространении экземпляров аудиовизуальных произведений и фонограмм", ст. 2, с изменениями от 10.7.2003года) [4, С. 235].

Для разработчика ИС существенным моментом при использовании концепции баз данных является то обстоятельство, что данные становятся определенным образом организованы, приобретают некую упорядоченность и внутреннюю структуру, а также то, что имеется некоторый набор унифицированных операций обработки данных и декларативных средств представления данных. К таким операциям следует отнести операции "Вставить" (Insert), "Добавить" (Add), "Удалить" (Delete) и ряд других. К декларативным средствам представления данных следует отнести языки определения данных. То есть использование данной концепции при создании ИС предполагает наличие языка определения данных и языка манипулирования данными, а также правил построения интерфейсов программ (приложений) с БД и пользователем.

Такое деление средств манипулирования данными и их представления является в определенной степени условным. Язык определения данных служит для описания логической структуры (схемы) БД, а в некоторых случаях и способов хранения и доступа к данным. Язык манипулирования данными предоставляет алгоритмические средства построения приложений для обработки сохраняемых в БД элементов данных.

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

Однако после признания концепции БД прошло почти четыре года, прежде чем в 1966 году была создана первая СУБД. На рис. 1.5 представлены основные функции СУБД.

Системой управления базами данных (Data-base Management System) называется совокупность программных средств, необходимых для использования базы данных и предоставляющих разработчикам и пользователям множество различных представлений данных [20, С. 113].

Рис. 1.5. Основные функции СУБД по [20]

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

Модель данных ограничивает возможность выбора СУБД, так как обычно отдельно взятая модель поддерживает определенную модель данных.

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

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

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

Что же такое модели данных? В самом общем случае модель данных - это логическое представление данных и совокупность операций над ними.

Модель данных (Data Model) есть логическая структура данных, которая представляет присущие этим данным свойства, не зависимые от аппаратного и программного обеспечения и не связанные с функционированием компьютера [21, С.122].

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

информационное моделирование:

концептуальное моделирование (моделирование семантики предметной области);

логическое моделирование данных;

физическое моделирование:

создание моделей доступа к данным;

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

Рассмотрим информационную модель данных. На рис. 1.6 иллюстрируется общее содержание понятия модели данных, сложившееся к настоящему времени.

Рис. 1.6. Представление об информационной модели данных по [21]

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

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

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

Исследовательская группа по СУБД ANSI/X3/SPARC пришла к выводу, что для создания идеальной среды управления данными необходимо определение их с третьей, промежуточной точки зрения (концепция трех схем ANSI/X3/SPARC). Эта точка зрения (называемая концептуальной схемой) сводится к единообразному определению данных в рамках предметной области, не ориентированному на какое-либо конкретное использование их и не зависящему от того, как данные физически обрабатываются на компьютере (рис. 1.7).

Основной целью концептуальной схемы является выработка непротиворечивой интерпретации определения взаимосвязей данных для их объединения, совместного использования и управления целостностью данных. Любая информационная модель данных определяется средствами поддержки модели данных, реализуемыми СУБД [21, С. 129].

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

Рис. 1.7. Концепция трех схем по [21]

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

Таблица 1.1 Общие характеристики моделей данных

Модель данных	Характер связи между объектами	Формальное представление
Сетевая	Полужесткие связи	Произвольный граф
Иерархическая	Жесткие связи	Древовидная структура
Реляционная	Изменчивые связи	Плоский файл

Рис. 1.8 иллюстрирует особенности каждой модели данных. При сопоставлении моделей следует помнить, что все они теоретически эквивалентны. Эквивалентность моделей состоит в том, что они могут быть сведены одна к другой путем формальных преобразований. Подробное доказательство этого факта можно найти в классической монографии Дж. Дейта по БД. Суть доказательства состоит в отказе от принципа избыточности данных, то есть разрешается дублировать данные в узлах представления. Тогда преобразование одной модели в другую получается простым удвоением вершин соответствующего представления в цепочке моделей "сетевая-иерархическая-реляционная" [22, С.28-29].

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

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

документальные, которые ориентированы на хранение документов;

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

Рис. 1.8. Основные типы моделей данных по [22]

Так, СУБД CDS/ISIS в первую очередь ориентирована на поддержку работы с документом, который состоит из определенного числа рубрик, проиндексированных по тезаурусу ключевых слов. СУБД ADABAS хорошо подходит для организации фактографических БД, а СУБД ORACLE - для БД смешанного типа. Во избежание несуразностей с использованием определенной модели данных, БД, за редким исключением, целесообразно классифицировать по типу используемой модели в СУБД. Отметим, что классификация БД далеко не завершенная область исследований: попытки ввести новые типы БД продолжаются (активные, дедуктивные, нечеткие реляционные, графические БД и т.д.).

Во многих случаях для разработчиков ИС бывает важно деление СУБД (и БД) по характеру обработки: на централизованные и распределенные. При использовании распределенной обработки следует обратить внимание на характер обработки транзакций, т.к. последние оказывают существенное влияние на производительность системы. Под транзакцией в самом общем случае понимают единицу работы, требуемой пользователем от БД, независимо от характера обработки. Чаще всего в результате обработки транзакции реализуется запрос пользователя либо на выборку данных из БД, либо на обновление БД, либо на выполнение каких-то иных действий над БД. При этом предполагается, что выполнение запроса сопровождается выполнением комплекса внутрисистемных действий СУБД, направленных на поддержание целостности данных, разграничение доступа и т.п.

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

1.2 Теория реляционных баз данных

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

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

Объект (или сущность) — это нечто существующее и различимое, то есть объектом можно назвать то "нечто", для которого существуют название и способ отличать один подобный объект от другого. Объектами могут быть не только материальные предметы, но и более абстрактные понятия, отражающие реальный мир [23, С.24].

Атрибут (или данные) — это некоторый показатель, который характеризует некий объект и принимает для конкретного экземпляра объекта некоторое числовое, текстовое или иное значение. Информационная система оперирует наборами объектов, спроектированными применительно к данной предметной области, используя при этом конкретные значения атрибутов (данных) тех или иных объектах [23, С.25].

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

Основоположником теории реляционных баз данных считается сотрудник фирмы IBM доктор Э. Кодд, опубликовавший 6 (июня 1970 г. статью A Relational Model of Data for Large-Shared Data Banks (Реляционная модель данных для больших коллективных банков данных). В этой статье впервые был использован термин "реляционная модель данных. Теория реляционных баз данных, разработанная в 70-х годах в США доктором Э. Коддом, имеет под собой мощную математическую основу, описывающую правила эффективной организации данных. Разработанная Э. Коддом теоретическая база стала основой для разработки теории проектирования баз данных.

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

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

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

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

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

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

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

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции — среди них не существует "первой", "второй", "последней". Любая таблица имеет один или несколько столбцов, значения в которых однозначно идентифицируют каждую ее строку. Такой столбец (или комбинация столбцов) называется первичным ключом (primary key). Часто вводят искусственное поле, предназначенное для нумерации записей в таблице. Таким полем, например, может быть его порядковый, который сможет обеспечить уникальность каждой записи в таблице. Ключ должен обладать следующими свойствами [30, С. 164]:

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

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

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

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

Взаимосвязь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).

Таблицы невозможно хранить и обрабатывать, если в базе данных отсутствуют "данные о данных", например, описатели таблиц, столбцов и т.д. Их называют обычно метаданными. Метаданные также представлены в табличной форме и хранятся в словаре данных (data dictionary).

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

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

Для того, чтобы гарантировать корректность и взаимную непротиворечивость данных, на базу данных накладываются некоторые ограничения, которые называют ограничениями целостности (data integrity constraints).

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

Категорная целостность;

Целостность на уровне ссылок;

Функциональные зависимости.

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

Требование целостности сущности полностью звучит следующим образом: у любой переменной отношения должен существовать первичный ключ, и никакое значение первичного ключа в кортежах значения-отношения переменной отношения не должно содержать неопределенных значений. Чтобы эта формулировка была полностью понятна, кратко обсудим понятие неопределенного значения (NULL) [23, С. 35].

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

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

Так вот, первое из требований — требование целостности сущности — означает, что первичный ключ должен полностью идентифицировать каждую сущность, а поэтому в составе любого значения первичного ключа не допускается наличие неопределенных значений. (В классической реляционной модели это требование распространяется и на возможные ключи, в SQL-ориентированных СУБД такое требование для возможных ключей не поддерживается).

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

Требование целостности по ссылкам, или требование целостности внешнего ключа, состоит в том, что для каждого значения внешнего ключа, появляющегося в кортеже значения-отношения ссылающейся переменной отношения, либо в значении-отношении переменной отношения, на которую указывает ссылка, должен найтись кортеж с таким же значением первичного ключа, либо значение внешнего ключа должно быть полностью неопределенным (т. е. ни на что не указывать) [23, С. 41].

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

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

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

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

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

Любая компания, производящая подобные СУБД, называет их реляционными системами. Очень важно отчетливо понимать, какие свойства таких систем действительно являются реляционными, а что в них не вполне соответствует исходным, ясным и строгим идеям реляционного подхода и даже противоречит им. Это поможет более правильно организовывать базы данных и строить приложения в среде SQL-ориентированной СУБД.

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

Обычно в современных реляционных базах данных допускается хранение символьных, числовых данных (точных и приблизительных), специализированных числовых данных (таких, как "деньги"), а также специальных "темпоральных" данных (дата, время, временной интервал). Кроме того, в реляционных системах поддерживается возможность определения пользователями собственных типов данных [21, С. 116].

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

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

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

По определению, первичным ключом переменной отношения является такое подмножество S множества атрибутов ее заголовка, что в любое время значение первичного ключа (составное, если в состав первичного ключа входит более одного атрибута) в любом кортеже тела отношения отличается от значения первичного ключа в любом другом кортеже тела этого отношения, а никакое собственное подмножество S этим свойством не обладает [20, С. 119].

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

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

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

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

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

Понятие первичного ключа является исключительно важным в связи с понятием целостности баз данных. Заметим, что хотя формально существование первичного ключа значения отношения является следствием того, что тело отношения – это множество, на практике первичные (и возможные) ключи переменных отношений появляются в результате явных указаний проектировщика отношения. Определяя переменную отношения, проектировщик моделирует часть предметной области, данные из которой будет содержать база данных. И конечно, проектировщик должен знать природу этих данных [17, С. 124].

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

Согласно трактовке Дейта, реляционная модель состоит из трех частей, описывающих разные аспекты реляционного подхода: структурной части, манипуляционной части и целостной части (К. Дейт, 2000).

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

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

Из всего вышесказанного следует, что классический подход к проектированию структур реляционных БД имеет следующие проблемы:

идентификация функциональных зависимостей;

трудоемкость идентификации всех функциональных зависимостей;

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

проблема идентификации сущностей и атрибутов сущностей.

1.3 Методы проектирования БД ИС

Методология создания информационных систем заключается в организации процесса построения информационной системы и в управлении этим процессом для того, чтобы гарантировать выполнение требований, как к самой системе, так и к характеристикам процесса разработки. [18, С.130]

Основными задачами, решение которых должна обеспечивать методология создания информационных систем (ИС) (с помощью соответствующего набора инструментальных средств), являются [18, С. 131]:

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

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

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

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

Основное содержание технологии проектирования составляют технологические инструкции, состоящие из описания последовательности технологических операций, условий, в зависимости от которых выполняется та или иная операция, и описаний самих операций. Данная технология может быть представлена как совокупность трех составляющих [9, С. 52]:

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

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

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

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

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

Поддерживать полный жизненный цикл информационной системы;

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

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

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

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

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

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

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

На небольшой команде программистов (обычно от 2 до 10 человек);

На тщательно проработанном производственном графике работ, рассчитанном на сравнительно короткий срок разработки;

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

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

CASE-средства (от Computer Aided Software/System Engineering) - позволяют проектировать любые системы на компьютере. Необходимый элемент системного и структурно-функционального анализа, CASE средства позволяют моделировать бизнес-процессы, базы данных, компоненты программного обеспечения, деятельность и структуру организаций [24, С. 55]

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

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

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

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

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

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

При разработке приложений с помощью инструментов RAD используются множество готовых объектов, сохраняемых в общедоступном хранилище. Однако имеется также возможность разработки новых объектов. При этом новые объекты могут разрабатываться как на основе существующих, так и "с нуля".

Инструментальные средства RAD обладают удобным графическим интерфейсом пользователя и позволяют на основе стандартных объектов формировать простые приложения без написания кода программы. Это является большим преимуществом RAD, так как в значительной степени сокращает рутинную работу по разработке интерфейсов пользователя (при использовании обычных средств разработка интерфейсов представляет собой достаточно трудоемкую задачу, решение которой отнимает много времени). Высокая скорость разработки интерфейсной части приложений позволяет быстро создавать прототипы и упрощает взаимодействие с конечными пользователями [24, С. 82].

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

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

Все наиболее распространенные методологии структурного подхода базируются на ряде общих принципов [29, С.104]. В качестве двух базовых принципов используются следующие:

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

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

Выделение двух базовых принципов не означает, что остальные принципы являются второстепенными, поскольку игнорирование любого из них может привести к непредсказуемым последствиям (в том числе и к провалу всего проекта). Основными из этих принципов являются следующие [29, С. 105]:

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

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

принцип непротиворечивости - заключается в обоснованности и согласованности элементов;

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

В структурном анализе используются в основном две группы средств, иллюстрирующих функции, выполняемые системой и отношения между данными. Каждой группе средств соответствуют определенные виды моделей (диаграмм), наиболее распространенной среди которых являятся: ERD (Entity-Relationship Diagrams) диаграммы "сущность-связь".

На стадии проектирования ИС модели расширяются, уточняются и дополняются диаграммами, отражающими структуру программного обеспечения: архитектуру ПО, структурные схемы программ и диаграммы экранных форм [26, С.108].

Семантическая модель (концептуальная модель, инфологическая модель) – модель предметной области, предназначенная для представления семантики предметной области на самом высоком уровне абстракции. Это означает, что устранена или минимизирована необходимость использовать понятия "низкого уровня", связанные со спецификой физического представления и хранения данных [22, С 139].

Семантическое моделирование стало предметом интенсивных исследований с конца 1970-х годов. Основным побудительным мотивом подобных исследований (т.е. проблемой, которую пытались разрешить исследователи) был следующий факт. Дело в том, что системы баз данных обычно обладают весьма ограниченными сведениями о смысле хранящихся в них данных. Чаще всего они позволяют лишь манипулировать данными определенных простых типов и определяют некоторые простейшие ограничения целостности, наложенные на эти данные. Любая более сложная интерпретация возлагается на пользователя. Однако было бы замечательно, если бы системы могли обладать немного более широким объемом сведений и несколько интеллектуальнее отвечать на запросы пользователя, а также поддерживать более сложные (т.е. более высокоуровневые) интерфейсы пользователя [25, С. 35].

Идеи семантического моделирования могут быть полезны как средство проектирования базы данных даже при отсутствии их непосредственной поддержки в СУБД.

Наиболее известным представителем класса семантических моделей является модель "сущность-связь" (ER-модель).Методология построения баз данных базируется на теоретических основах их проектирования. Для понимания концепции методологии приведем основные ее идеи в виде двух последовательно реализуемых на практике этапов:

1-й этап - обследование всех функциональных подразделений фирмы с целью:

понять специфику и структуру ее деятельности;

построить схему информационных потоков:

проанализировать существующую систему;

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

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

Модель Сущность-Связь (ER-модель) (англ. entity-relationship model (ERM) или англ. entity-relationship diagram (ERD)) — модель данных, позволяющая описывать концептуальные схемы. Предоставляет собой графическую нотацию, основанную на блоках и соединяющих их линиях, с помощью которых можно описывать объекты и отношения между ними какой-либо другой модели данных. В этом смысле ER-модель является мета-моделью данных, то есть средством описания моделей данных [25, С. 37].

Модель "сущность-связь" была предложена в 1976 году Питером Пин-Шен Ченом (англ. Peter Pin-Shen Chen) – американским профессором компьютерных наук в университете штата Луизиана. Фактически Чен не изобретал модель, он взял идеи из более ранних работ таких практиков, как А. Браун и других. Однако Питер Чен сделал больше, чем кто бы то ни было до него для формализации и популяризации ER-модели, а также для её внедрения в научную литературу.

В связи с наглядностью представления концептуальных схем баз данных ER-модели получили широкое распространение в системах CASE, поддерживающих автоматизированное проектирование реляционных баз данных. Среди множества нотаций ER-моделей одна из наиболее развитых – Unified Modeling Language (Унифицированный язык моделирования), сокр. UML – применяется в системе CASE фирмы ORACLE. Нотация UML так же используется и/или поддерживается: Borland Software Corporation, Университетом Бремена, Университетом Кента, Университетом.

Основные преимущества ER-моделей [6, С. 68]:

наглядность;

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

ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin, Oracle Designer).

Основные элементы ER-моделей:

объекты (сущности);

атрибуты объектов;

связи между объектами.

Сущность - любой объект предметной области, имеющий атрибуты.

Связь между сущностями характеризуется:

типом связи (1:1, 1:М, М:М);

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

Концептуальное (инфологическое) проектирование – построение формализованной модели предметной области. Такая модель строится с использованием стандартных языковых средств, обычно графических, например ER-диаграмм. Такая модель строится без ориентации на какую-либо конкретную СУБД.

Основные элементы данной модели:

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

Описание информационных потребностей пользователей (описание основных запросов к БД).

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

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

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

Логическое (даталогическое) проектирование – отображение инфологической модели на модель данных, используемую в конкретной СУБД, например на реляционную модель данных. Для реляционных СУБД даталогическая модель – набор таблиц, обычно с указанием ключевых полей, связей между таблицами. Если инфологическая модель построена в виде ER-диаграмм (или других формализованных средств), то даталогическое проектирование представляет собой построение таблиц по определённым формализованным правилам, а также нормализацию этих таблиц. Этот этап может быть в значительной степени автоматизирован [25, С. 40].

Физическое проектирование – реализация даталогической модели средствами конкретной СУБД, а также выбор решений, связанных с физической средой хранения данных: выбор методов управления дисковой памятью, методов доступа к данным, методов сжатия данных и т.д. – эти задачи решаются в основном средствами СУБД и скрыты от разработчика БД [25, С. 42].

На этапе инфологического проектирования в ходе сбора информации о предметной области требуется выяснить:

основные объекты предметной области (объекты, о которых должна храниться информация в БД);

атрибуты объектов;

связи между объектами;

основные запросы к БД.

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

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

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

Выводы по Разделу 1

В разделе 1 один были рассмотрены информационные системы и информация, методы обработки данных, основные концепции обработки данных (концепция файловой системы, концепция баз данных, концепция объективно – ориентированных баз данных), основные функции СУБД. Рассмотрены модели данных: сетевая, иерархическая, реляционная. Подробно была описана реляционная модель данных.

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

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

Выбрать концептуальную модель, с помощью которой будет построена концептуальная схема;

Построить точное описание семантических ограничений, поддерживаемых выбранной СУБД;

Построить отображение выбранной концептуальной модели в модель данных, поддерживаемую СУБД.

Определить, что такое хорошая схема и описать методику ее построения.

2. Анализ и оценка финансового состояния ГП "Алушталифт"

2.1 Организационная характеристика предприятия

Государственное предприятие "Алушталифт" основано на государственной форме собственности и находится в сфере управления Республиканского комитета жилищно-коммунального хозяйства Автономной республики Крым (орган управления имуществом).

Предприятие является правопреемником реорганизационного Государственного Специализированного Ремонтно-Строительного Управления "Крымлифт", в части объемов работ и активов хозрасчетного специализированного ремонтно-строительного участка "Алушталифт".

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

Руководителем предприятия является Гопоненко Татьяна Владимировна. Крымское республиканское предприятие "АЛУШТАЛИФТ г.Алушта" находиться по адресу г. Алушта, ул. Октябрьская 30.

Основной задачей Государственного предприятия "АЛУШТАЛИФТ" является обеспечение бесперебойной и безаварийной работы лифтов городе Алушта; эксплуатация, техническое обслуживание и ремонт диспетчерских систем.

Предметом деятельности предприятия является:

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

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

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

- обследование технического состояния лифтов и составление дефектных ведомостей, выполнение технических освидетельствований лифтов в объеме ПУБЭЛ, выполнение электроизмерительных работ на лифтах;

- оказание складских услуг;

- грузовые и пассажирские перевозки всеми видами транспорта, экспедиторские услуги;

- юридические услуги

- услуги по капремонту, монтажу, техобслуживанию и наладке оборудования.

Функции:

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

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

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

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

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

6. В соответствии с целями производства решает задачи:

а) обеспечение безопасности производственных процессов, оборудования, зданий и сооружений;

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

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

г) выбор оптимальных режимов труда и отдыха работающих.

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

8. Проводит оперативно-методическое руководство всей работой, в т.ч. по охране труда.

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

10. Проводит работникам первичные инструктаж по вопросам охраны труда.

Контролирует соблюдение работниками правил и норм ОТ и ТБ, производственной и трудовой дисциплины, правил внутреннего трудового распорядка. Проводит воспитательную работу в коллективе.

Производственная структура предприятия представлена на рисунке 2.1.

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

В прямом подчинении у директора находятся:

- главный инженер предприятия (1);

- главный бухгалтер (1);

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

- у главного инженера:

- Диспетчер;

- Служба ЛАС;

- Электромеханик ЛАС;

- Электромеханик по ремонту лифтов;

- Водители;

Рис. 2.1. Производственная структура ГП "Алушталифт" г.Алушта

Оперативное руководство предприятием осуществляется Главным инженером предприятия, в соответствии с полномочиями, определенными в Уставе предприятия. Работой отделов руководят начальники цехов, отделов, подразделений – среднее управленческое звено. В соответствии со штатным расписанием должность Главного инженера введена на предприятии для организации и исполнения правовых, организационно-технических, санитарно-гигиенических, социально-экономических мероприятий, трудовых ресурсов на всех участках хозяйственной деятельности предприятия. Главный инженер предприятия назначается на должность приказом директора предприятия.

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

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

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

В ГП "АЛУШТАЛИФТ г.Алушта" штат работников включает 29 человек. Работающих пенсионеров – 4 человека. Работники прошедшие курсы повышения квалификации - 7 человек.

Возрастной уровень персонала:

1) с 18 до 25 лет – 7 человек;

2) с 25 до 30 лет – 6 человек;

3) с 35 до 45 лет – 5 человек;

4) с 45 до 55 лет – 3 человека;

5) с 55 до 60 лет – 4 человека;

6) Свыше 60 лет – 4 человека;

Образовательный уровень персонала:

1) работники имеющие высшее образование – 6 человек;

2) работники имеющие среднее - специальное образование – 17 человек.

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

2.2 Экономическая характеристика предприятия, статистический анализ и оценочные показатели

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

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

Таблица 2.1 Оценка имущества ГП "Алушталифт" по составу

№ п/п	Показатели	2007	2008	2009	Измене-ние 2008-2007	Измене-ние 2009-2008	Измене-ние 2009-2007
1.	Всего имущества, тыс.грн.,	287,80	272,70	250,00	-15,10	-22,70	-37,80
2.	Необоротные активы, тыс.грн	50,60	46,60	42,20	-4,00	-4,40	-8,40
	% к имуществу	17,58%	17,09%	16,88%	-0,49	-0,21	-0,70
3	Оборотные активы, тыс.грн.	237,20	226,10	207,80	-11,10	-18,30	-29,40
3.1	Материал. оборотные активы, тыс.грн.	13,60	15,60	14,20	2,00	-1,40	0,60
	% к оборот. активам	5,73%	6,90%	6,83%	1,17	-0,07	1,10
3.2	Денежные средства, тыс.грн.	0,70	4,50	5,10	3,80	0,60	4,40
	% к оборот. активам	0,30%	1,99%	2,45%	1,70	0,46	2,16
3.3	Дебиторская задолженность, тыс.грн	222,90	206,30	188,50	-16,60	-17,80	-34,40
	в % к оборотным активам	93,97%	91,24%	90,71%	-2,73	-0,53	-3,26

Из представленных данных в таблице 2.1 следует, что в составе имущества предприятия произошли следующие изменения: оборотные активы уменьшились на 8,4 тыс.грн., в то время как оборотные активы уменьшились на протяжении лет на 29,4 тыс.грн., при этом в связи с уменьшением количественного показателя всего имущества на начало 2009 года. Это привело к структурным изменениям имущества предприятия, а именно, доля необоротных активов уменьшилась, соответственно доля оборотных активов увеличилась, на 0,7 пункта.

Следует отметить немаловажный факт: очень высокий удельный вес в составе оборотных активов занимает дебиторская задолженность (около 90%), в составе всего имущества ей принадлежит 75% (в 2009 году). Именно снижение дебиторской задолженности на 34,4 тыс.грн. за исследуемый период привело к снижению всех оборотных активов и уменьшению стоимости имущества на 37,8 тыс.грн. На рисунке 2.4 показана динамика изменения состава имущества предприятия.

Из данной тенденции можно сделать следующие выводы:

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

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

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

а) фондов будет меньше, чем нужно;

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

Рис. 2.2. Динамика изменения состава имущества ГП "Алушталифт"

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

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

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

Таблица 2.2 Оценка производственных активов ГП "Алушталифт"

№ п/п	Показатели	Ед. изм.	2007	2008	2009
1.	Основные средства	тыс.грн.	50,60	46,60	42,20
22.	Производственные запасы	тыс.грн.	13,60	15,60	14,20
33.	Незавершенное производство	тыс.грн.	0,00	0,00	0,00
44.	Всего производственных активов, (стр.1+стр.2+стр.3)	тыс.грн.	64,20	62,20	56,40
55.	Всего имущества	тыс.грн.	287,80	272,70	250,00
66.	Удельный вес производственных активов в имуществе предприятия	%	22,31	22,81	22,56

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

Рис. 2.3 Динамика изменения удельного веса производственных активов ГП "Алушталифт"

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

Из рисунка 2.3 следует, что для данного предприятия характерен низкий удельный вес производственных активов в имуществе: 22,31% на начало анализируемого периода и 22,56% на конец (доля производственных запасов в составе всего имущества существенно изменилась). Незначительное увеличение (на 0,25пункта) связано с уменьшением стоимости имущества предприятия на 37,8 тыс.грн., на которое в свою очередь повлияло, как уже отмечалось ранее, снижение дебиторской задолженности. В составе и структуре оборотных активов произошли следующие изменения:

Материальные оборотные активы, представляющие собой производственные запасы на данном предприятии, в 2007 году увеличилась на 2,0 тыс.грн., а в 2008 году уменьшилась на 1,2 тыс.грн., в целом произошло увеличение на 0,6 тыс.грн. Это изменение связано с уменьшением основных средств в структуре производственных запасов и должно быть сопоставлено с нормативом, то есть с потребностью, необходимой для производственной деятельности.

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

Для анализируемого предприятия характерен очень высокий удельный вес дебиторской задолженности в составе оборотных активов (93,37% на начало анализируемого периода и 90,71 на конец) по отношению к всему имуществу (77% в 2007 году и 75% в 2009 году) Такое положение может быть расценено следующим образом :

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

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

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

Перейдем к анализу имущества по источникам формирования ( т.е определим какие изменения произошли в структуре собственного и заемного капитала) и представим данные в Таблице 2.3

Таблица 2.3 Анализ имущества ГП "Алушталифт" по источникам формирования

№ п/п	Показатели	2007	2008	2009	Измене- ние 2008-2007	Измене- ние 2009-2008	Измене- ние 2009-2007
1.	Всего имущества, тыс.грн.,	287,80	272,70	250,00	-15,10	-22,70	-37,80
2.	Собственный капитал, тыс.грн	118,30	103,60	51,60	-14,70	-52,00	-66,70
	% к имуществу	41,10	37,99	20,64	-3,11	-17,35	-20,46
2.1	Собственные оборот. средства, тыс.грн.	67,70	57,00	9,40	-10,70	-47,60	-58,30
	% к капиталу	57,23	55,02	18,22	-2,21	-36,80	-39,01
3	Заемные средства тыс.грн	169,50	169,10	198,40	-0,40	29,30	28,90
	% к имуществу	58,90	62,01	79,36	3,11	17,35	20,46
3.1	Кредиторская задолженность за услуг тыс.грн	37,10	47,00	21,70	9,90	-25,30	-15,40
	в % к текущим обязательствам	21,97	27,89	10,94	5,93	-16,96	-11,03
3.2	Текущие обязательства тыс.грн	129,50	104,40	68,10	-25,10	-36,30	-61,40
	в % к текущим обязательствам	76,97	61,96	34,32	-14,71	-27,63	-42,35

Из представленных данных в таблице 2.3 следует, что стоимость имущества предприятия уменьшилась на 37,8 тыс.грн или на 13 процентов. В составе источников произошли следующие изменения: собственный капитал значительно сократился на (66,7 тыс.грн. или в 2,3 раза), заемные и привлеченные источники увеличились на 28,9 тыс.грн. (на 17%). Это в свою очередь, привело к следующим структурным изменениям: удельный вес собственного капитала уменьшился на 20,46 пункта, соответственно доля заемных и привлеченных источников увеличилась на 20,46 пункта. Заемных и привлеченных средств на 100 % представлены текущими обязательствами, из них: на начало периода 21,47% и 10,94% 0- на конец приходится кредиторской задолженности за услуги, остальные 76,67% на начало периода и 34,32% на конец – текущие обязательства по расчетам, 53,68% краткосрочных кредитов банков приходится на конец анализируемого периода.

Изменение соотношения собственного и заемного капитала наглядно представлены на Рисунке 2.4.

Рис. 2.4. Динамика изменения структуры имущества ГП "Алушталифт" по источникам формирования

На предприятии произошло значительное уменьшение величины наличия собственных оборотных средств (см. рисунок 2.5) на 58,3 тыс.грн. или на 86,1%.

Рис. 2.5. Динамика изменения оборотных средств ГП "Алушталифт"

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

Наличие собственных оборотных средств по данным баланса составило:

На начало 2008 года = 118,3 – 50,6 = 67,7 (тыс.грн.)

На начало 2009 года = 103,6 – 46,6 = 57,0 (тыс.грн.)

На начало 2010 года = 51,6 – 42,2 = 9,40 (тыс.грн.)

Данная динамика сокращения собственных оборотных средств в составе собственного капитала на 58,3 тыс.грн. и увеличения заемного капитала предприятия на 29,5 тыс.грн. свидетельствует о том. Что у предприятия возникнут в будущем трудности в осуществлении своих платежей (расчетов).

Целесообразно сопоставить остатки дебиторской и кредиторской задолженности и вывести сальдо задолженностей за каждый период. Полученные данные приведены в таблице 2.4. Из таблицы видно, что в 2007-2009 гг. наблюдалось превышение дебиторской задолженности над кредиторской, тогда как к концу 2009 года кредиторская задолженность превысила дебиторскую на 9,8 тыс.грн.

Таблица 2.4 Сальдо задолженности в 2007-2009 гг.

Виды задолженности	Ед.измерения	2007	2008	2009
Кредиторская задолженность	тыс.грн.	168,9	168,5	198,4
Дебиторская задолженность	тыс.грн.	223,0	206,4	188,6
Сальдо задолженности	тыс.грн.	54,1	37,9	-9,8

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

Рис. 2.6 Динамика изменения величины и соотношения дебиторской и кредиторской задолженности ГП "Алушталифт"

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

1. Индекс постоянного актива (ИПА), показывающий часть основных средств и необоротных активов в источниках формирования собственных средств:

ИПА2007 = 50,6/118,3 = 0,22

ИПА2008 = 46,6/103,6 = 0,45

ИПА2009 = 42,2/51,6 = 0,82

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

2. Коэффициент реальной стоимости имущества (КРС), показывающий какую часть в стоимости имущества составляют средства производства:

КРС2007 = (50,6 + 13,6) / 287,8 = 0,22

КРС2008 = (46,6 + 15,6) / 272,7 = 0,23

КРС2009 = (42,2 + 14,2) / 250 = 0,23

Таким образом, в период с 2007 года по 2009 год доля средств производства в стоимости имущества практически не изменилась и составила 23% на конец 2009 года. Значения коэффициента реальной стоимости имущества не должно быть ниже, чем 0,5. Величина КРС на года говорит о высокой дебиторской задолженности на протяжении исследуемого периода, что должно насторожить как само предприятие, так и его партнеров. Финансовая устойчивость предприятия тесно связана с перспективой его платежеспособности. Ее оценка дает возможность определить финансовые возможности предприятия на соответствующую перспективу. Перейдем к оценке финансовой устойчивости ГП "Алушталифт". Проанализируем систему коэффициентов, характеризующих изменение финансовой устойчивости исследуемого предприятия за период с 2007 года по 2009 год, и представим в виде таблицы 2.5:

Таблица 2.5 Показатели финансовой устойчивости ГП "Алушталифт"

Коэффициенты	2007 г.	2008 г.	2009.г
Коэффициент автономии	0,41	0,38	0,21
Коэффициент финансовой зависимости	2,43	2,63	4,84
Коэффициент финансового риска	1,43	1,63	3,84
Коэффициент маневренности собственного капитала	1,34	1,22	0,22

На рисунке 2.7 приведена динамика финансовой устойчивости предприятия.

Рис. 2.7 Коэффициенты финансовой устойчивости ГП "Алушталифт"

Коэффициент автономии (финансовой независимости, покрытие) снизился к концу 2009 года в 2 раза и составил 0,21 (нормативное значение 0,5), т.е доля собственного капитала в общей величине источников средств составляет 21%. Такая ситуация обусловлена привлечением значительных кредитных средств, доля которых в общей величине имущества предприятия составила 42,6%.

Коэффициент финансовой зависимости, показывающей долю привлеченных средств в сумме средств финансирования, на протяжении исследуемого периода возрастал (с 2,43 в 2007 году до 4,84 в 2009 году, т.е увеличился в 2 раза), что говорит об утрате финансовой независимости предприятием.

Общую оценку финансовой устойчивости дает коэффициент финансового риска (коэффициент соотношения заемного капитала и собственного), показывающий сколько заемных средств приходится на 1 грн. Собственных средств предприятия, вложенных в активы. На исследуемом предприятии данный показатель возрастал и составил 3,84 в 2009 году (увеличился в 2,7 раза по сравнению с уровнем 2007 года), т.е заемные средства в 3,84 раза превышают собственный капитал. Что свидетельствует о неустойчивом финансовом положении. Коэффициент маневренности собственного капитала, показывающий, какая часть собственного оборотного капитала находится в обороте, а какая капитализируется, в 2009 году снизился в 6 раз по сравнению с 2007 годом (снизился на 1,12) и составил 0,22. Таким образом, собственные средства в основном капитализированы, а оборотные средства формируются за счет привлеченных средств (кредитов). Все вышесказанное позволяет говорить о том, что к концу 2009 года хозяйствующий субъект находился в кризисном неустойчивом финансовом состоянии, т.е данное состояние характеризуется ситуацией, при которой предприятие имеет займы, непогашенные в срок, и просроченную дебиторскую и кредиторскую задолженность.

Выводы по Разделу 2

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

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

3. Разработка и проектирование БД ИС на предприятии ГП "АЛУШТАЛИФТ"

3.1 Проектирование БД ИС "Вызов"

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

При выполнении данного процесса решаются следующие основные задачи:

обеспечение хранения в БД всей необходимой информации;

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

сокращение избыточности и дублирования данных;

обеспечение целостности данных (правильности их содержания): исключение противоречий в содержании данных, исключение их потери и т.д.

В процессе написания был использован язык SQL, так как базовым требованием к реляционным СУБД является наличие мощного и в тоже время простого языка, позволяющего выполнять все необходимые пользователям операции. В последние годы таким повсеместно принятым языком стал язык реляционных БД SQL - Structured Query Language.

На основе описания предметной области во втором разделе и ER метода проектирования баз данных, описанной в первом разделе, разработаем модель базы данных проектируемой ИС.

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

Для каждой заявки будет заводиться отдельная строка в таблице базы данных, в которой указываются:

Номер вызова;

Дата вызова;

№ лифта;

Вид работы;

Лифтер.

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

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

"Вид ремонта", где будет показано его описание, какова цена и нужный допуск работника;

"Выбор лифта", где будет список из лифтов с указанием точного адреса и номера подъезда;

"Календарь", где надо будет выбрать дату получения заявки;

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

Согласно ER – методу проектирования на первом этапе определяем сущности и их атрибуты. При проектировании БД ИС ГП "Алушталифт" выделены следующие сущности:

Дом;

Вызов;

Лифт;

Ремонтные работы;

Лифтер.

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

Сущность "дом" включает в себя следующие атрибуты: код дома, город и адрес. Ключевое поле "Рег. № дома";

Сущность "вызов" включает в себя следующие атрибуты: код вызова, код работы, код лифтера, код лифта и дату вызова. Ключевое поле "номер вызова";

Сущность "лифт" включает в себя следующие атрибуты: код лифта, имя, тип лифта, тип дверей, подъезд и код дома. Ключевое поле "С/№ лифта";

Сущность "ремонтные работы" включает в себя следующие атрибуты: код работы, тип работы, цена, описание и допуск работника. Ключевое поле "Код рем. Работы";

Сущность "лифтер" включает в себя следующие атрибуты: код лифтера, ФИО, адрес лифтера, допуск и дату приема на работу. Ключевое поле "Рег. № лифтера"

На втором этапе проектирования определим степени связей между сущностями и класс принадлежностей. Предположим что в вызове может находится множество ремонтных работ, в то время как ремонтная работа может относится только к одному вызову. Ремонтные работы обязаны, относится к вызову, а вызов должен включать в себя ремонтные работы. Таким образом, степень связи между отношениями "ремонтные работы" и "вызов" - один ко многим (1:N), а класс принадлежности N – связной сущности – обязательный. Следовательно, по правилу 4 генерации предварительных отношений достаточным является наличие двух отношений, по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен в качестве атрибута в отношение, отводимое N-связной сущности.

Аналогичным образом в вызове может находится множество лифтов, в то время как лифт относится только к одному вызову. Лифт обязан относится к вызову, а вызов должен включать в себя лифт. Таким образом, степень связи между отношениями "лифт" и "вызов" - один ко многим (1:N), класс принадлежности – обязательный. Следовательно, по правилу 4 генерации предварительных отношений достаточным является наличие двух отношений, по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен в качестве атрибута в отношение, отводимое N-связной сущности.

В вызове может находится множество лифтеров, но лифтер может относится только к одному вызову. Лифтер обязан относится к вызову , а вызов должен включать в себя лифтера. Таким образом, степень связи между отношениями "лифтер" и "вызов" - один ко многим (1:N), класс принадлежности – обязательный. Следовательно, по правилу 4 генерации предварительных отношений достаточным является наличие двух отношений, по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен в качестве атрибута в отношение, отводимое N-связной сущности.

В лифте может содержатся множество домов, но дом может содержать только один лифт. Дом обязан относится к лифту, а лифт должен включать в себя дом. Таким образом, степень связи между отношениями "дом" и "лифт" - один ко многим (1:N), класс принадлежности – обязательный. Следовательно, по правилу 4 генерации предварительных отношений достаточным является наличие двух отношений, по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен в качестве атрибута в отношение, отводимое N-связной сущности.

В результате мы получили инфологическую модель БД ИС "Вызов" в виде ER – диаграммы (см. Рис. 3.1)

Рис 3.1. ER – диаграмма БД ИС "Вызов"

На основе полученной инфологической модели построим даталогическю модель в виде просто сети (см. Рис. 3.2)

Рис 3.2. Даталогическая модель БД ИС "Вызов"

Теперь мы можем на основе даталогической модели построить физическую модель БД ИС "Вызов" в нотации СУБД Paradox.

Рис 3.3. Физическая модель БД ИС "Вызов"

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

3.2 Разработка БД ИС "Вызов" в среде Delphi 7

Для обеспечения доступа к данным из таблиц при создании приложения использовался модуль данных (DM), на котором размещены компоненты Table и DataSource. Для этих компонентов была выбрана база данных ware (созданный alias). Модуль данных изображен на рисунке 3.4.

Рис 3.4. Модуль данных

Для реализации SQL запросов, которые используются приложением , в модуль данных были добавлены еще несколько компонентов TQuery и DataSource.

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

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

Рис. 3.5. Главное окно программы "Вызов"

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

При нажатии на кнопку "добавить" добавление заявки будет происходить при следующей обработки события OnClick для формы "Вызов":

If dm.MENDopuskM.Value>=DM.WORKDopuskW.Value then

dm.CALL.Append

else MessageBox(0, PChar('Не соответствует допуск работника!!'), PChar('Внимание'), mb_Right);

If dm.MENDopuskM.Value>=DM.WORKDopuskW.Value then

DM.call['KodLift']:=DM.HLKodLift.Value

else dm.CALL.Append;

If dm.MENDopuskM.Value>=DM.WORKDopuskW.Value then

DM.call['KodLiftMen']:=DM.MENKodLiftMen.Value

else dm.CALL.Append;

If dm.MENDopuskM.Value>=DM.WORKDopuskW.Value then

DM.call['KodWork']:=DM.WORKKodWork.Value

else dm.CALL.Append;

If dm.MENDopuskM.Value>=DM.WORKDopuskW.Value then

DM.call['DateCall']:=monthcalendar1.Date

else dm.CALL.Append;

If dm.MENDopuskM.Value>=DM.WORKDopuskW.Value then

DM.CALL.Post

else DM.CALL.Delete;

Для того что бы добавить нового лифтера нам надо открыть форму "Лифтеры" нажав в главном окне кнопку "Добавить лифтера" (см. рис. 3.6).

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

Рис. 3.6. Форма "Лифтеры"

При нажатии на кнопку "добавить" происходит событие OnClick для формы "Лифтеры":

DM.MEN.Append;

DM.MEN['KodLiftMen']:=edit1.Text;

DM.MEN['FIO']:=edit2.Text;

DM.MEN['AdressM']:=edit3.Text;

DM.MEN['DopuskM']:=radiogroup1.ItemIndex;

DM.MEN['DateTrud']:=monthcalendar1.Date;

dm.MEN.Post;

edit1.Text:='';

edit2.Text:='';

edit3.Text:='';

Вся необходимая информация о ремонтных работах содержится в форме "Ремонт" (см. рис. 3.6). При появлении новых видов работ, их можно добавить в базу при помощи той же формы.

Информация о новых ремонтных работах вносится при помощи формы "Ремонт" со вкладки "Вызов".

Рис. 3.7 Форма "Ремонт"

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

DM.WORK.Append;

DM.WORK['KodWork']:=edit1.Text;

DM.WORK['Type']:=edit2.Text;

DM.WORK['Price']:=edit3.Text;

DM.WORK['Type_txt']:=memo1.Text;

DM.WORK['DopuskW']:=radiogroup1.ItemIndex;

DM.WORK.Post;

edit1.Text:='';

edit2.Text:='';

edit3.Text:='';

memo1.Text:='';

Аналогичным способом выполнена форма "Лифт" (см. рис. 3.8).

Здесь можно увидеть список текущих лифтов с описанием их характеристик, таких как: код лифта, имя, тип лифта, тип дверей. Номер подъезда и код дома.

Рис. 3.8. Форма "Лифты"

Для добавления нового лифта мы заполняем следующие поля: С/н лифта, название, тип двигателя, тип дверей, номер подъезда и дом. Для удобства ввода данных поля "номер подъезда" и "Дом" выполнены с помощью элемента DBLookupComboBox. Для того чтобы не вводить каждый раз эту информацию вручную, её можно выбрать из выпадающего списка. Эта форма очень удобно для добавления новых лифтов которое предприятие будет обслуживать в будущем.

При нажатии на кнопку "Добавить" будет происходит следующие событие OnClick для формы "Лифты":

DM.Lift.Append;

DM.Lift['KodLift']:=edit1.Text;

DM.Lift['Name']:=edit2.Text;

DM.Lift['TypeDvig']:=edit3.Text;

DM.Lift['TypeDoor']:=edit4.Text;

DM.Lift['Podezd']:=ComboBox1.text;

DM.Lift['KodDom']:=DM.HomeKodDom.Value;

DM.Lift.Post;

edit1.Text:='';

edit2.Text:='';

edit3.Text:='';

edit4.Text:='';

При необходимости добавления нового дома в форме "Лифты" нужно нажать на кнопку добавить дом. При этом откроется форма "Дом" (см. рис. 3.9).

Рис. 3.9. Форма "Дома"

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

При нажатии на кнопку "Добавить" будет происходит следующие событие OnClick для формы "Дом":

DM.HOME.Append;

DM.HOME['KodDom']:=edit1.Text;

DM.HOME['City']:=edit2.Text;

DM.HOME['Adress']:=edit3.Text;

DM.HOME.Post;

edit1.Text:='';

edit2.Text:='';

edit3.Text:='';

В БД ИС "Вызов" есть система отчетов для удобного просмотра выполненных работ, при необходимости их можно отпечатать, передать в другие инстанции или для выставления счета заказчику. Для того что бы просмотреть отчет в форме "Вызов" нажмите в меню "Отчет", далее откроется форма "Отчет" в которой есть три вкладки: отчет по дате, отчет по работнику, отчет по городу.

В отчете по дате можно просмотреть, сколько было заявок в определенный день (см. рис. 3.10).

Рис. 3.10. Отчет по дате

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

Рис. 3.11. Отчет по работнику

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

Рис. 3.12. Отчет по городу

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

3.3 Внедрение БД ИС "Вызов" и оценка эффективности

При изучении процесса внедрения ИС на предприятиях анализ проводят по нескольким направлениям, связанным с определением:

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

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

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

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

Итак, для принятия решения о внедрении корпоративной ИС (или отдельных ее модулей) необходимо уделить внимание следующим вопросам:

обоснованию необходимости внедрения ИС;

определению сдерживающих сил изменения;

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

этапам внедрения ИС;

оценке результатов внедрения ИС.

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

Затраты на разработку распределяются между двумя видами работ: научно-исследовательскими и опытно-конструкторскими. В рамках данной дипломной работы предусматривается расчет затрат на выполнения только научно-исследовательских работ (НИР). Удельные капиталовложения на создание БД ИС "Вызов" составляют 750 грн.

Расчет экономической эффективности от использования БД ИС "Вызов" как элемента новой технологии проектирования и внедрения вычисляется по формуле 3.1.

(3.1)

Где, Э – годовой экономический эффект от использования БД ИС "Вызов" в вычислительных процессах, грн;

З1,З2 – приведенные затраты на единицу работ, выполненных с помощью новой БД ИС "Вызов" и без нее, грн;

А2 – годовой объем работ выполняемых с помощью новой БД ИС "Вызов" в расчетном году, натуральных еденицах.

Приведенные затраты (З2) на единицу работы рассчитываются по формулам 3.2, 3.3.

(3.2)

(3.3)

Где С1, С2 – себестоимость единицы работ производимых без использования БД ИС "Вызов" и с помощью него, грн;

К1, К2 капитальные вложения, связанные с использованием БД ИС "Вызов" (К1) и без него (К2), грн;

Ен – нормативный коэффициент экономической эффективности капитальных вложений, равный 0,15.

Себестоимость единицы работ (С1, С2) определяется по формулам 3.4, 3.5.

(3.4)

(3.5)

Где заработная плата составляет 830 грн.

N0 – количество документов обработанных без компьютера (до 50);

N1 – количество документов обработанных с применением БД ИС "Вызов" (до 90);

Следовательно, себестоимость составит:

(3.6)

(3.7)

Удельные капитальные вложения не связанные с использованием БД ИС "Вызов" рассчитываются по формуле 3.8.

(3.8)

В свою очередь в капитальные затраты отнесены: электроэнергия 140 грн. в месяц,

Подставив значения в формулу 3.8 получим:

(3.9)

Удельные капиталовложения, связанные с использованием БД ИС "Вызов" формула 3.10.

(3.10)

В свою очередь в LCM отнесены затраты в размере 910 грн.

(3.11)

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

(3.12)

(3.13)

Для годового объема выполненных работ с помощью БД ИС "Вызов" необходимо использовать формулу 3.14.

(3.14)

Исходя из формулы 3.14 годовой объем выполненных работ при помощи БД ИС "Вызов" равен:

(3.15)

Зная все необходимые данные можно рассчитать годовой экономический эффект от использования БД ИС "Вызов" по формуле 3.1.

Полученная величина свидетельствует об эффективности внедрения БД ИС "Вызов" на предприятии, так как за счет увеличения количества документов, уменьшаются затраты выполненные на единицу работ (см. рис.3.12), следовательно экономический эффект увеличивается. А значит внедрение данного программного продукта на предприятии становится выгодным. Благодаря тому, что все движение заявок на ремонт фиксируется в базе данных и к этим данным обеспечивается удобный доступ, обеспечивается свободный контроль за выполнением заявок. Это упрощает расчет показателей, необходимых для принятия управленческих решений. Таких как, например, анализ выполненных работ определенным сотрудником, плановые объемы работ.

Внедренная БД ИС "Вызов" позволила:

сократить двух диспетчеров;

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

получать различные отчеты по заявкам;

сократить процент ошибок при заполнение;

уменьшить затраты на бумажную документацию;

Рис. 3.12. Затраты на единицу работы

Подводя итог сказанному можно отметить, что внедряя базу данных на предприятие ГП "Алушталифт" мы обеспечиваем экономию времени и снижение затрат на обработку заявок. Все это положительно скажется на финансовом положение предприятия. Оперативный анализ выполнение заявок дает возможность предприятию отказаться от невыгодных и/или убыточных заказов и заключить новые договора на обслуживания лифтов, что в будущем принесет дополнительную прибыль, позволит выйти из неустойчивого финансового положения. В итоге, благодаря разработанной БД ИС руководитель сможет вести оптимальную деятельность предприятия.

Выводы по разделу 3

В данном разделе основываясь на ER – метод проектирования была построена инфологическая модель в виде ER – диаграммы и уже на основе ее была разработана даталогическая модель в виде простой сети. Были определены степени связей между сущностями и классы принадлежностей. Степени связи между отношениями данной БД ИС - один ко многим (1:N), а класс принадлежности N-связной сущности — обязательный. Следовательно, по правилу 4 генерации предварительных отношений достаточным является наличие двух отношений, по одному на каждую сущность, при условии, что ключ сущности служит в качестве первичного ключа для соответствующего отношения. Дополнительно ключ 1-связной сущности должен быть добавлен в качестве атрибута в отношение, отводимое N-связной сущности.

По данной модели была создана база данных, установлены связи между таблицами и обеспечена целостность данных. Так же было разработано приложение для автоматизации оформления заявок —"Вызов". Приложение состоит из пяти форм и обладает интуитивно понятным интерфейсом. Для работы с приложением "Вызов" достаточно базовых знаний работы с ПК. Представлены способы получения отчетов из составленных баз данных. Обоснована экономическая эффективность внедрения данной информационной системы.

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

Заключение

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

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

В ходе данной дипломной работы была создана база данных с применением современного средства разработки приложений Borland Delphi 7.0. В ней реализованы все основные аспекты современных баз данных, в том числе язык запросов SQL.

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

В ходе работы над программой были изучены методы проектирования баз данных и работа с ними, исследована методология проектирования по предметной области, изучен один из наиболее используемых языков для создания запросов SQL, изучен язык программирования Object Pascal, реализованный в среде программирования Delphi 7.

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

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

Экономический анализ эффективности деятельности предприятия в результате внедрения БД ИС "Вызов" показал что программный продукт позволил уменьшить затраты на 30 коп. на единицу продукции. Что является хорошим результатом и может повысить экономические показатели предприятия, и упростить работу сотрудников по оформлению заявок на обслуживание лифтов.

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

Список литературы

1. Закон Украины "Об Информации" от 02.10.1992 № 2657-XII // Урядовий кур'єр. – 2005. – № 252. – 17 грудня.

2. Закон Украины "Об информации, информатизации и защите информации" от 02.10.1992 г. № 2657-XII // Урядовий кур'єр. – 2005. – № 252. – 17 грудня.

3. Указ Президента Украины о "Положении о технической защите информации в Украине", от 27.09.99 г. № 1229/99 // Урядовий кур'єр. – 2006. – № 60. – 20 липня.

4. Закон Украины "О распространении экземпляров аудиовизуальных произведений и фонограмм" от 10.7.2003 № 1098-IV // Урядовий кур'єр. – 2005. – № 256. – 28 грудня.

5. Архангельский А. Н. Программирование в Delphi / А. Н. Архангельский. - 7 М.: Библио-Пресс, 2003. – 256 с.

6. Ахмадеев И. А Базы данных. Учебное пособие / И. А. Ахмадеев., Хайруллин А.Х, Юрасов С.Ю. – Н. Челны.: КГПИ, 2004. – 224 с.

7. Бобровский С. В. Delphi 7. Учебный курс / С. В. Бобровский Информ-Пресс: Питер, 2003. – 362 с.

8. Воройский Ф. С. Информатика. Новый систематизированный словарь-справочник (Вводный курс по информатике и вычислительной технике в терминах). — 2-е изд / Ф.С. Воройский. – Издательство Либерия, 2001. – 315 с.

9. Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс / Гарсиа-Молина Г, Ульман Дж, Уидом Дж. — М.: "Вильямс", 2003. – 229 с.

10. Грачев А. В. Анализ и управление финансовой устойчивостью предприятия / А. В. Грачев. – М.: Финпресс., 2002. – 387 с.

11. Дика В. В. Информационные системы в экономике / В. В. Дика. – М.: Финансы и статистика, 2006. – 295 с.

12. Данилова О. Д. Финансовая деятельность предприятий / О. Д. Данилова. – К.: КомпьютерПресс, 2005. – 316 с.

13. Зиндер Е. З. Новое системное проектирование: информационные технологии и бизнес- реинжиниринг (вторая часть) / Е. З. Зиндер. – К.: Центр учебной литературы, 1996. – 338 с.

14. Избачков Ю. С., Петров В. Н. Информационные системы: Учебник для Вузов, 2 / Ю. С. Избачков, В. Н. Петров. – изд. СПб.: Питер, 2006. – 275 с.

15. Ионин Е. Е. Финансовый анализ: Учеб. Пособие / Е. Е. Ионин. – Донецк: ДонНУ., 2002. – 331 с.

16. Калянов Г. Н. CASE. Структурный системный анализ (автоматизация и применение) / Г. Н. Калянов. – М.: "Лори", 2006. – 175 с.

17. Коннолли Т. М, Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика / Т. М. Коннолли, К. Бегг. – М.: Издательский дом "Вильямс", 2003. – 261 с.

18. Когаловский М. Р. Перспективные технологии информационных систем / М. Р. Когаловский. — М.: ДМК Пресс; Компания АйТи, 2003. – 415 с.

19. Когаловский М. Р. Энциклопедия технологий баз данных / М. Р. Когаловский. — М.: Финансы и статистика, 2002. – 352 с.

20. Кузнецов С. Д. Основы баз данных. — 2-е изд / С. Д. Кузнецов. — М.: Интернет-Университет ИТ; Бином. Лаборатория знаний, 2007. – 233 с.

21. Кузнецов С. Д. Базы данных: Вводный курс / С. Д. Кузнецов. – М.: Бином, 2008.

22. Дейт. К. Дж. Введение в системы баз данных / К. Дж. Дейт. — "Вильямс", 2001. – 426 с.

23. Мейер М. Теория реляционных баз данных / М. Мейер. – М.: Мир, 1987. – 280 с.

24. Мюллер Р. Дж. Базы данных и UML. Проектирование / Р. Дж. Мюллер. – М.: ЛОРИ, 2002. – 193 с.

25. Пономаренко В. С Информационные системы и технологии в экономики / В. С. Пономаренко. – Киев: Академия, 2002. – 542 с.

26. Саймон А. Р. Стратегические технологии баз данных / А. Р. Саймон. – М.: Финансы и статистика, 1999. 457 с.

27. Станиславчик Е. Н. Основы финансового менеджмента / С. Н. Станиславчик. – М.: Ось, 2001. – 450 с.

28. Туманов В. Е. Введение в SQL для баз данных в архитектуре "клиент-сервер" / В. Е. Туманов, Б. Н. Гайфуллин, В. Я. Сгибнев. – М.: Интерфейс Пресс, 2000. – 289 с.

29. Туманов В. Е Архитектуры баз данных для крупных промышленных предприятий / В. Е. Туманов. – М.: Машиностроитель, 2005. – 401 с.

30. Харрингтон Д. Л Проектирование реляционных баз данных. Просто и доступно / Д. Л. Харрингтон. – М.: ЛОРИ, 2000. – 277 с.

31. Эонстантайн Л. Разработка программного обеспечения / Л. Эонстантайн, Л. Локвуд. – СПБ.: Питер 2004. – 431 с.