Содержание
1. Структура информационной системы. Техническое, математическое и программное обеспечение системы. Привести примеры2
2. Типы информационных систем. Информационные системы в фирме. Составить структурную схему. Привести пример6
3. 1С:Бухгалтерия 7.711
Список литературы21
Выдержка из текста работы
- Введение
- Глава 1. Теория проектирования АИС
- 1.1 Понятие и классификация АИС
- 1.1.1 Структура ИС
- 1.1.2 Этапы проектирования ИС
- 1.2 Корпоративные информационные системы
- 1.2.1 Тенденции развития корпоративных ИС
- 1.2.2 Классификация корпоративных информационных систем и требования к ним
- Глава 2. Проектирование базы данных и приложения
- 2.1 Проектирование БД
- 2.1.1 Состав и функции СУБД
- 2.1.2Требования к организации базы данных
- 2.1.3 Основные концепции реляционных баз данных
- 2.1.4 Нормализация баз данных
- 2.2 Проектирование приложения
- 2.2.1 Выбор системы проектирования и реализации
- Глава 3. Разработка ИС учета договоров на предприятии
- 3.1 Общее описание БД реализованной системы
- 3.1.1 Шаги проектирования БД
- 3.1.2 Описание предметной области
- 3.1.3 Инфологическое проектирование
- 3.1.4 Даталогическое проектирование
- 3.2 Общее описание разработанного приложения
- 3.2.1 Логическая структура приложения
- 3.2.2 Интерфейс и основные функции приложения
- Заключение
- Список использованных источников
- Введение
В настоящее время, несмотря на повышение компьютеризации общества, зачастую задачи документооборота решаются вручную, без использования современных вычислительных средств. Связано это, зачастую с нежеланием пользователей — исполнителей осваивать новые технологии обработки данных, их недостаточной квалификацией, нежеланием руководства тратить значительное количество времени и материальных средств на ввод новых технологией. Отчасти эта позиция оправдана, так как не всегда использование новых средств себя полностью оправдывает и окупает. Как правило, это связано с ошибками при проектировании и вводе в эксплуатацию систем обработки данных. Существующий опыт создания ИС показывает, что реальная автоматизация в большинстве случаев не приводит к сокращению персонала, а снижение затрат является лишь косвенным фактором автоматизации. Главная задача автоматизации — приобретение принципиально новых качеств. Процесс автоматизации осуществляется в различных масштабах, т.е. от отдельных задач до создания функционально полных автоматизированных ИС. В данной работе предпринята попытка в достаточной мере автоматизировать процесс учета договоров подряда на примере строительной фирмы ООО «Строй-Сервис».
О своевременности и актуальности рассматриваемой проблемы говорит тот факт, что большую часть своего времени должностные лица тратят на оформление различной документации и отчетов. Выгоды, выражающиеся в экономии времени при работе, и отсутствие предложений в данной сфере обеспечивают высокую потребность в данном продукте.
В качестве СУБД для данной дипломной работы была выбрана СУБД MS Access. Графический интерфейс реализован в Borland Delphi.
Глава 1. Теория проектирования АИС
1.1 Понятие и классификация АИС
АИС представляет собой совокупность информации, экономико-математических методов и моделей, технических, программных, технологических средств и специалистов, предназначенную для обработки информации и принятия управленческих решений.
АИС являются одним из наиболее распространенных классов систем обработки данных. Они используют ресурсы нескольких категорий — средства вычислительной техники, системное и прикладное программное обеспечение, информационные, лингвистические и человеческие ресурсы. К категории информационных систем часто относят многие системы обработки данных, которые не только поддерживают информационную модель предметной области, но и позволяют решать на ее основе некоторые классы задач управленческого, исследовательского, конструкторского или иного характера. Конкретные задачи, которые должны решаться информационной системой, зависят от той прикладной области, для которой предназначена система. Области применения информационных приложений разнообразны: банковское дело, страхование, медицина, транспорт, образование и т. д.
Первые информационные системы появились в 50-х гг. В 70-х — начале 80-гг. информационные системы начинают широко использоваться в качестве управленческого контроля, поддерживающего и ускоряющего процесс принятия решений. К концу 80-х гг. концепция использования информационных систем вновь изменяется, они становятся стратегическим источником информации и используются на всех уровнях организации любого профиля.
Основные требования к АИС:
1) интегрируемость — способность взаимодействия системы с вновь подключаемыми компонентами или подсистемами;
2) масштабируемость — возможность расширения системных ресурсов и производительной мощности;
3) управляемость — возможность гибкого управления системой;
4) адаптивность — возможность системы приспосабливаться к условиям конкретной предметной области;
5) используемость — возможность реализации заложенных в систему функций;
6) реактивность — способность системы реагировать на внутренние и внешние воздействия;
7) безопасность — возможность предотвращения разрушения системы в результате несанкционированного доступа.
Качество АИС определяется совокупностью свойств, характеризующих способность АИС удовлетворять потребности ее пользователей. Выделяют функциональные, экономические и эксплуатационные показатели качества АИС. Функциональные показатели характеризуют: функциональную полноту, адаптивность и корректность АИС. Экономические показатели — это стоимость создания или приобретения АИС, затраты на её внедрение и эксплуатацию, эффект, получаемый от функционирования АИС. Эксплуатационные — это показатели, определяющие набор требований к техническим средствам, характеризующие возможность работы в сети, характеризующие легкость и простоту установки, надежность программного обеспечения, удобство его освоения, качество помощи и пользовательского интерфейса, возможность защиты данных.
Построение информационной системы должно осуществляться в соответствии с основными принципами системного подхода к сложным информационным системам:
1) принцип конечной цели — абсолютный приоритет конечной (глобальной) цели. Предполагает, что на этапе разработки технического задания на систему в целом и на информационную систему необходимо четко и с максимальной детальностью сформулировать цели, достигаемые с помощью информационной системы, и способы их реализации. При этом должна быть рассмотрена возможность оценки на разных стадиях развития системы, степени ее соответствия намеченным целям;
2) принцип функционального разбиения — система разбивается на подсистемы по функциональному признаку;
3) принцип совмещения функциональной и организационной структур — в каждой большой системе можно выделить собственно систему данного уровня и автономные системы более низких уровней. Система данного уровня делится на функциональные подсистемы, которые являются частями системы, выполняющими определенные функции. Функциональная подсистема не является автономной, она не может работать вне данной управляющей системы, в то время как автономная управляющая система выполняет все виды деятельности системы, но в меньшем масштабе. Таким образом, каждая большая система состоит из управляющей системы данного уровня и определенного количества автономных систем более низких уровней. Автономные системы самых низких уровней иерархии могут включать в себя только функциональные подсистемы;
4) принцип единства — совместное рассмотрение системы как целого и как совокупности частей (подсистем);
5) принцип функциональности — совместное рассмотрение структуры и функций с приоритетом функций над структурой. Принцип функциональности утверждает, что любая структура тесно связана с функцией системы и ее частей, и создавать структуру необходимо после четкого осознания функций системы;
6) принцип развития — учет изменяемости системы, ее способность к расширению, развитию, замене модулей;
7) принцип децентрализации — сочетание централизации и децентрализации в построении модулей и системы в целом. Принцип децентрализации рекомендует, чтобы управляющие воздействия и принятие решений исходили не только из главного модуля, как при полной централизации, но и из подсистем более низкого уровня;
8) принцип неопределенности — учет возможности возникновения непредвиденных или неопределенных ситуаций при эксплуатации системы. Для исключения влияния таких ситуаций на работоспособность системы необходимо применять дублирование наиболее ответственных подсистем, оценивать при разработке наихудшие ситуации в системе и проектировать в расчете на них;
9) принцип защищенности информации — охватывает все меры, которые предпринимаются для обеспечения сохранности медико-санитарных данных от шагов, которые умышленно или неумышленно могут привести к изменениям, потере или раскрытию этих данных;
10) принцип унификации — близкие по своим функциям модули должны быть унифицированы;
11) принцип поэтапности ввода информационной системы в эксплуатацию;
12) принцип универсальности — предполагает возможность тиражирования модулей информационной системы.
Автоматизированные информационные системы классифицируются по ряду признаков:
1) Сфера функционирования объекта управления:
a) АИС сельского хозяйства;
b) АИС транспорта;
c) АИС связи и т.д.
2) Виды процессов управления:
a) АИС управление технологическими процессами;
b) АИС управления организационно-технологическими процессами;
c) АИС организационного управления;
d) АИС научных исследований;
e) обучающие АИС.
3) Уровень в системе государственного управления:
a) отраслевые АИС;
b) территориальные АИС;
c) межотраслевые АИС.
АИС управления технологическими процессами — это человеко-машинные системы, обеспечивающие управление технологическими устройствами, станками, автоматическими линиями.
АИС управления организационно-технологическими процессами представляют собой многоуровневые системы, сочетающие АИС управления технологическими процессами и АИС управления предприятиями.
Для АИС организационного управления объектом служат производственно-хозяйственные, социально-экономические, функциональные процессы, реализуемые на всех уровнях управления экономикой, в частности:
1) банковские АИС;
2) АИС фондового рынка;
3) финансовые АИС;
4) страховые АИС;
5) налоговые АИС;
6) АИС таможенной службы;
7) статистические АИС;
8) АИС промышленных предприятий и организаций.
АИС научных исследований обеспечивают высокое качество и эффективность межотраслевых расчетов и научных опытов. Методической базой таких систем служат экономико-математические методы, технической базой — вычислительная техника и технические средства для проведения экспериментальных работ моделирования.
Обучающие АИС получают широкое распространение при подготовке специалистов в системе образования, при переподготовке и повышении квалификации работников разных отраслей.
Отраслевые АИС функционируют в сферах промышленного и агропромышленного комплексов, в строительстве, на транспорте. Эти системы решают задачи информационного обслуживания аппарата управления соответствующих ведомств.
Территориальные АИС предназначены для управления административно-территориальными районами. Деятельность территориальных систем направлена на качественное выполнение управленческих функций в регионе, формирование отчетности, выдачу оперативных сведений местным государственным и хозяйственным органам.
Межотраслевые АИС являются специализированными системами функциональных органов управления национальной экономикой (банковских, финансовых, снабженческих, статистических и др.). Имея в своем составе мощные вычислительные комплексы, межотраслевые многоуровневые АИС обеспечивают разработку экономических и хозяйственных прогнозов, государственного бюджета, осуществляют контроль результатов и регулирование деятельности всех звеньев хозяйства, а также контроль наличия и распределения ресурсов.
Определяя АИС как организованную для достижения общей цели совокупность специалистов, средств вычислительной и другой техники, математических методов и моделей, интеллектуальных продуктов и их описаний, а также способов и порядка взаимодействия указанных компонентов, следует выделить, что главным звеном и управляющим субъектом в перечисленном комплексе элементов был и остается человек, специалист.
В современных условиях функционирования информационных технологий нет четкого различия между пользователем системы и разработчиком. Сегодня существуют готовые инструментальные программные средства, которые позволяют методом интерпретации быстро разрабатывать собственные программно-ориентированные продукты — пакеты прикладных программ. Для этого нужно быть хорошим специалистом в своей области и в меньшей степени владеть программированием [2].
1.1.1 Структура ИС
АИС, как всякая другая система, состоит из элементов (подсистем), находящихся в определенных отношениях друг с другом. Множество этих отношений совместно с элементами образуют структуру АИС. Выделяют функциональную и обеспечивающую части АИС.
Функциональная часть представляет собой совокупность формализованных функциональных задач, обеспечивающих реализацию определенных функций управления. Она обслуживает определенные виды деятельности экономического объекта, характерные для его структурных подразделений или функций управления. Состав функциональной части АИС во многом определяется особенностями экономического объекта: его отраслевой принадлежностью, формой собственности, размером, характером деятельности.
Разделение функциональной части АИС на подсистемы зависит от применяемого принципа декомпозиции:
1) предметный принцип;
2) функциональный принцип;
3) проблемный принцип;
4) смешанный (предметно-функциональный) принцип.
Если в основу функциональной части АИС положен предметный принцип, то подсистемы выделяют в соответствии с управлением отдельными ресурсами экономического объекта:
1) сбыт готовой продукции;
2) производство;
3) материально-техническое снабжение;
4) финансы;
5) кадры.
При использовании функционального принципа декомпозиции, подсистемы выделяют с учетом функций управления:
1) планирование;
2) регулирование;
3) учет и контроль;
4) анализ.
В соответствии с проблемным принципом декомпозиция функциональных подсистем отражает необходимость принятия управленческих решений по отдельным проблемам, например, бизнес-планирование, управление проектами и др.
На практике чаще всего применяется смешанный принцип декомпозиции:
1) перспективное развитие;
2) технико-экономическое планирование;
3) бухгалтерский учет и анализ хозяйственной деятельности;
4) техническая подготовка производства;
5) управление производством;
6) управление качеством продукции;
7) управление материально-техническим снабжением;
8) управление реализацией и сбытом готовой продукции;
9) управление кадрами.
Обеспечивающая часть АИС состоит из подсистем, являющихся общими для всей АИС, независимо от состава ее функциональной части. В состав обеспечивающей части входят подсистемы: программного обеспечения, информационного обеспечения, технического обеспечения, организационного обеспечения, математического обеспечения, лингвистического обеспечения (рис. 1.1).
Рисунок 1.1 — Структура информационной системы как совокупность обеспечивающих подсистем
Математическое обеспечение — это совокупность математических методов, моделей и алгоритмов обработки информации.
К средствам математического обеспечения относятся:
1) средства моделирования процессов управления;
2) типовые задачи управления;
3) методы математического программирования, математической статистики, теории массового обслуживания и др.
Программное обеспечение — это совокупность программ, реализующих функции и задачи АИС и обеспечивающих устойчивую работу технических средств.
В состав программного обеспечения входят общесистемные и специальные программные продукты, а также техническая документация.
К общесистемному программному обеспечению относятся комплексы программ, ориентированных на пользователей и предназначенных для решения типовых задач обработки информации. Они служат для расширения функциональных возможностей компьютеров, контроля и управления процессом обработки данных.
Специальное программное обеспечение представляет собой совокупность программ, разработанных при создании конкретной информационной системы. В его состав входят пакеты прикладных программ, реализующие разработанные модели разной степени адекватности, отражающие функционирование реального объекта.
Техническая документация на разработку программных средств должна содержать описание задач, задание на алгоритмизацию, экономико-математическую модель задачи, контрольные примеры.
Информационное обеспечение — это совокупность решений по объемам, размещению и формам организации информации, циркулирующей в АИС.
Назначение подсистемы информационного обеспечения состоит в своевременном формировании и выдаче достоверной информации для принятия управленческих решений.
Схемы информационных потоков отражают маршруты движения информации, ее объемы, места возникновения первичной информации и использования результатной информации.
Методология построения баз данных базируется на теоретических основах их проектирования. Концепция методологии представлена в виде двух последовательно реализуемых на практике этапов:
1-й этап — обследование всех функциональных подразделений фирмы с целью:
1) понять специфику и структуру ее деятельности;
2) построить схему информационных потоков;
3) проанализировать существующую систему документооборота;
4) определить информационные объекты и соответствующий состав реквизитов.
2-й этап — построение концептуальной информационно-логической модели данных для обследованной на 1-м этапе сферы деятельности. В этой модели должны быть установлены и оптимизированы все связи между объектами и их реквизитами.
Техническое обеспечение — это комплекс технических средств, обеспечивающих работу АИС (средства сбора, регистрации, передачи, обработки, отображения, размножения информации).
Организационное обеспечение — совокупность методов и средств, регламентирующих деятельность персонала в условиях функционирования АИС.
Правовое обеспечение — это совокупность правовых норм, и документов, регламентирующих правоотношения при создании и внедрения АИС.
В состав правового обеспечения входят законы, указы, постановления государственных органов власти, приказы, инструкции и другие нормативные документы министерств, ведомств, организаций, местных органов власти. В правовом обеспечении можно выделить общую часть, регулирующую функционирование любой информационной системы, и локальную часть, регулирующую функционирование конкретной системы.
Лингвистическое обеспечение включает совокупность научно-технических терминов и других языковых средств, используемых в АИС (традиционные языки: естественные, математические, алгоритмические, языки моделирования; языки специального назначения: информационно-поисковые языки, языки СУБД, языки операционных систем и входные языки пакетов прикладных программ).
Перечисленные подсистемы различаются по структурному признаку, т.е. каждой обеспечивающей подсистеме соответствует совокупность элементов независимо от сферы применения.
1.1.2 Этапы проектирования ИС
Разработка ИС — это трудоемкий, длительный и динамический процесс, состоящих из нескольких этапов.
Проектирование имеет целью обеспечить эффективное функционирование ИС и её взаимодействие со специалистами, использующими в сфере деятельности конкретного экономического объекта ПЭВМ и развитые средства коммуникации для выполнения своих профессиональных задач и принятия управленческих решений.
Проектированием ИС называется процесс составления описания еще не существующей системы на разных языках и с различной степенью детализации, в ходе, которого осуществляется оптимизация проектных решений. В процессе детализации описаний наступает момент, когда имеющиеся описания позволяют создать действующую систему и наступает период эксплуатации ИС.
Жизненный цикл (ЖЦ) — период создания и использования ИС, охватывающей ее различные состояния, начиная с момента возникновения необходимости в данной информационной системе и заканчивая моментом ее полного выхода из употребления у пользователей.
Жизненный цикл ИС позволяет выделить четыре основные стадии:
Рисунок 1.2 — Стадии жизненного цикла ИС
1 стадия — предпроектное обследование:
1-й этап — сбор материалов для проектирования — формирование требований, изучение объекта проектирование, разработка и выбор варианта концепции системы;
2-й этап — анализ материалов и формирование документации — создание и утверждение технико-экономического обоснования и технического задания на проектирование системы на основе анализа материалов обследования, собранных на первом этапе.
2 стадия — проектирование:
1-й этап — техническое проектирование, где ведется поиск наиболее рациональных проектных решений по всем аспектам разработки, создаются и описываются все компоненты системы, а результаты работы отражаются в техническом проекте;
2-й этап — рабочее проектирование, в процессе которого осуществляется разработка и доводка программ, корректировка структур баз данных, создание документации на установку технических средств и инструкций по их эксплуатации, подготовка для каждого пользователя системы обширного инструкционного материала, оформленного в виде должностных инструкций исполнителям-специалистам, реализующим свои профессиональные функции с использованием технических средств управления. Технический и рабочий проекты могут объединяться в единый документ — техно-рабочий проект.
3 стадия — ввод системы в действие:
1-й этап — подготовка к внедрению — установка и ввод в эксплуатацию технических средств, загрузка баз данных и опытная эксплуатация программ, обучение персонала;
2-й этап — проведение опытных испытаний всех компонентов системы перед передачей в промышленную эксплуатацию, обучение персонала;
3-й этап — завершающая стадия создания ИС) — сдача в промышленную эксплуатацию; оформляется актами приема-передачи работ.
4 стадия — промышленная эксплуатация — кроме повседневного функционирование включает сопровождение программных средств и всего проекта, оперативное обслуживание и администрирование баз данных.
Жизненный цикл образуется в соответствии с принципом нисходящего проектирования и, как правило, носят итерационный характер: реализованные этапы, начиная с самых ранних, циклически повторяются в соответствии с изменениями требований и внешних условий, введением ограничений и т.д. На каждом этапе проектирования определяется набор документов и технических решений, при этом для каждого этапа исходными являются документы и решения, полученные на предыдущем этапе. Этап завершается проверкой предложенных решений и документов на их соответствие сформулированным требованиям и начальным условиям.
Главная особенность разработки ИС состоит в концентрации сложности на стадиях предпроектного обследования и проектирования и относительно невысокой сложности и трудоемкости последующих этапов. Более того, нерешенные вопросы и ошибки, допущенные на этапах анализа и проектирования, порождают на этапах внедрения и эксплуатации трудные, часто неразрешимые проблемы и, в конечном счете, приводят к отказу от использования материалов проекта [3].
1.2 Корпоративные информационные системы
1.2.1 Тенденции развития корпоративных ИС
Эволюция мировой индустрии ИТ включает четыре этапа. Начальный этап соответствует использованию разнотипных и плохо совместимых друг с другом мини-ЭВМ и мейнфреймов в интересах ограниченных производственных коллективов, четвертый этап рассматривается как Информационное Общество, в котором информационные услуги будут доступны любому клиенту. Между этими этапами лежат разнообразные сетевые приложения, характеризующие второй и третий этапы. В развитии ИС также выделяют четыре этапа:
1) первоначально гегемоном была централизованная модель обработки на базе мейнфреймов;
2) на втором этапе эволюции ИС на смену централизованной модели на базе мейнфреймов в связи с бурным развитием и массовым использованием персональных компьютеров (ПК) в сетях стала преобладать распределенная архитектура одноранговых сетей ПК;
3) затем, на третьем этапе, началось возвратное движение к централизации ресурсов системы на основе получивших в настоящее время всеобщее признание технологии «клиент-сервер» и архитектуры открытых систем;
4) отличительная черта приходящего четвертого этапа — это иерархическая организация, где централизованная обработка и единое управление ресурсами ИС на верхнем уровне сочетается с распределенной обработкой на нижнем. Такая организация отвечает идеологии корпоративных Интернет\Экстранет\Интранет-технологий, она обеспечивает: полное использование потенциала ПК и среды распределенной обработки в сочетании с управляемостью информационными ресурсами в корпоративном смысле, а потому именно за этой идеологией будущее в концепциях создания и использования ИС в образовании и науке.
Для использования в образовании, отличающимся многоранговостью и обширной тематической раздробленностью предметных областей изучения, упомянутая концепция четвертого этапа эволюции ИС хороша еще и тем, что среди ее особенностей модульное построение информационной системы. Это позволяет выстраивать ИС по многомодульному принципу с четким делением по назначению устойчивых модульных наполнения ядер ИС и изменяющимся гибким составом гипермодульных информационных окружений.
Одним из важнейших аспектов развития и последующего использования продуктов индустрии ИТ является корреляция между ИТ и производственной структурой, использующей ее в интересах реализуемого бизнес-процесса (бизнес-стратегии).
Бизнес-стратегия — это набор стратегий, рынков, предписаний, технологий производства продуктов и ресурсов, выбранных корпорацией для достижения поставленных целей. Информационная платформа, в свою очередь, охватывает компьютерные технологии, применяемые в корпорации, и способы, которыми эти технологии могут быть использованы для повышения конкурентоспособности выпускаемой продукции. Информационная архитектура — это совокупность конкретных архитектур и продуктов, выбранных для реализации информационной платформы.
Применительно к оценке роли бизнес-стртегии в концептуальном моделировании ИС в образовании уместно сделать несколько следующих реплик:
— существует двунаправленное воздействие бизнес-стратегии корпорации и ее информационной платформы;
— если бизнес-стратегия или информационная платформа меняется, то соответствующая наследуемая ИТ-архитектура также требует изменений;
— соответствие между бизнес-структурой и информационной платформой является решающим фактором успеха в деятельности корпорации, но на его достижение могут уйти годы. Этот вывод является самым главным в оценке соответствия целей, возможностей, перспектив и целесообразности создания той или иной ИС в образовании [4].
1.2.2 Классификация корпоративных информационных систем и требования к ним
Современная корпоративная ИС — это модель распределенной обработки, дополненная новым элементом — узлом концентрации, превратившим ее по сути в централизованную сеть. Сообразно взглядам специалистам на пришедшем рубеже столетий выделяются три основных типа или модели ИС с централизованной сетевой организацией: большая, средняя и малая. Отличительной особенностью большой модели ИС является наличие двух уровней сетей: базовой сети, связывающей информационные узлы концентрации, и множества локальных сетей, обеспечивающих пользователям взаимный доступ к корпоративным ресурсам. Средняя и малая ИС утрачивают эту особенность, переходя от двухуровневой архитектуры к одноуровневой, а в малых ИС — к сугубо ограниченной обеспечением местной автономной локальной сети вне взаимодействия этих ИС с другими ИС в других сетях, включая мировую глобальную систему WWW в Интернете. Независимо от принадлежности ИС к большим, средним или малым их архитектура должна отвечать основным требованиям к архитектуре современной ИТ:
— максимальная доступность, когда каждый пользователь может получить доступ к информационно-технологическим ресурсам в любое время и из любого места;
— одновременная доступность любого информационного объекта многим пользователям;
— маневренность приложений, обеспечиваемая наилучшим образом на основе архитектуры [5].
Глава 2. Проектирование базы данных и приложения
2.1 Проектирование БД
2.1.1 Состав и функции СУБД
СУБД — система данных, организованных специальным образом, сюда относятся базы данных, программные, языковые, организационнометрические средства, которые предназначены для обеспечения централизованного накопления и коллективного многоцелевого использования данных [6].
Рисунок 2.1 — Состав системы управления базой данных
Функции СУБД:
1) Определение данных. СУБД должна допускать определения данных (внешние схемы, концептуальную схему, внутреннюю схему, а также все связанные отображения) в исходной форме и преобразовывать эти определения в форму соответствующих объектов. СУБД должна включать в себя компонент языкового процессора, должна понимать синтаксис языка определений данных.
2) Обработка данных. СУБД должна уметь обрабатывать запросы пользователя на выборку, изменение, добавление данных, должна включать в себя компонент процессора языка обработки данных.
3) Безопасность и целостность данных. СУБД должна контролировать пользовательские запросы и пресекать попытки нарушения правил безопасности и целостности.
4) Восстановление и дублирование данных. СУБД должна осуществлять необходимый контроль над восстановлением и дублированием данных.
5) Словарь данных. СУБД должна обеспечить функцию словаря данных (в данном случае подразумевается «хранилище данных» и «энциклопедия данных»). Словарь содержит данные о данных (метаданные), расширенный словарь включает перекрестные ссылки, показывающие, какие из программ какую часть БД используют.
6) Производительность. СУБД должна выполнять все перечисленные функции с максимальной эффективностью [7].
MySQL — очень быстрая, надежная система управления реляционными базами данных (СУРБД). База данных позволяет эффективно хранить, искать, сортировать и получать данные. Сервер MySQL управляет доступом к данным, позволяя работать с ними одновременно нескольким пользователям, обеспечивает быстрый доступ к данным и гарантирует предоставление доступа только имеющим на это право пользователям. Следовательно, MySQL является многопользовательским, многопотоковым сервером.Он применяет SQL (Structured Query Language язык структурированных запросов), используемый по всему миру стандартный язык запросов в базы данных. MySQL появился на рынке в 1996 г., но его разработка началась еще в 1979 г. В настоящее время, по прошествии трех лет своего существования, эта система завоевала приз читательских симпатий журнала Linux Journal.
В настоящее время пакет MySQL доступен как программное обеспечение с открытым исходным кодом, но в случае необходимости можно получить и коммерческие лицензии.
К конкурентам MySQL, помимо прочих, относятся PostgreSQL, Microsoft SQL Server и Oracle. MySQL обладает многими преимуществами, в том числе высокой производительностью, низкой стоимостью, простотой конфигурирования и изучения, переносимостью и доступностью исходного кода. Более подробно упомянутые преимущества рассматриваются ниже.
Производительность.
MySQL без сомнений работает очень быстро. Результаты сравнительных тестов производительности, выполненных фирмой-изготовителем, можно посмотреть на странице http://web.mysql.com/benchmark.html. Многие из этих сравнительных тестов показывают, что MySQL работает на порядок быстрее конкурирующих продуктов.
Низкая стоимость.
Пакет MySQL доступен бесплатно в соответствии с лицензией на программное обеспечение с открытым исходным кодом или, если это необходимо для приложения, за небольшую сумму можно приобрести коммерческую лицензию.
Простота использования.
В большинстве современных баз данных используется SQL. Если ранее вы работали с другими СУРБД, переход к этой системе не должен вызывать какие-либо затруднения. Установка MySQL столь же проста, как и установка многих аналогичных продуктов.
Переносимость.
MySQL можетиспользоваться в среде многих различных систем UNIX, а также в среде Microsoft Windows.
Исходный код.
Как и в случае РНР, исходный код MySQL можно выгружать и изменять[8].
информационный система база данные
2.1.2 Требования к организации базы данных
Ядром СУБД является БД. БД представляет собой совокупность взаимосвязанных, хранящихся вместе данных при наличии такой минимальной избыточности, которая допускает их использование оптимальным образом для одного или нескольких приложений. Данные запоминаются так, чтобы они были независимы от программ, использующие эти данные; открыты для добавления новых или модификации существующих данных. Для поиска данных в базе применяется общий управляемый способ.
Быстрое развитие информационных потребностей прикладных систем требует разнообразных подходов к созданию сложных и простых баз данных. Сложность базы данных определяется объемами и структурой информатизации, разнообразием ее видов, множественностью связей между файлами, требованиями к производительности и надежности. В связи с этим были выделены основные требования к организации баз данных:
1) база данных — это основа для будущего наращивания прикладных программ. Базы данных должны обеспечивать возможность разработки приложений легче, быстрее, дешевле;
2) многократное использование данных — пользователи, которые по-разному понимают одни и те же данные, могут использовать их различным образом;
3) сохранение затрат умственного труда — существующие программы и логические структуры данных не переделываются при внесении изменений в базу данных;
4) простота — пользователи могут легко узнать и понять, какие данные имеются в их распоряжении;
5) легкость использования — пользователи имеют простой доступ к данным; сложный доступ к данным осуществляет СУБД;
6) гибкость использования — обращение к данным или их поиск осуществляется с помощью различных методов доступа;
7) быстрая обработка незапланированных запросов на данные — случайные запросы на данные могут обрабатываться с помощью высокоуровневого языка запросов или языка генерации отчетов, а не прикладными программами, написанными с целью обработки конкретных запросов;
8) простота внесения изменений. База данных может увеличиваться и изменяться без нарушения имеющихся способов использования данных;
9) небольшие затраты — низкая стоимость хранения и использования данных и минимизация затрат на внесение изменений;
10) уменьшение избыточности данных — требования новых приложений удовлетворяются за счет существующих данных, а не путем создания новых файлов;
11) производительность — запросы на данные удовлетворяются с такой скоростью, которая требуется для использования данных;
12) достоверность данных и соответствие одному уровню обновления. Необходимо использовать контроль над достоверностью данных. Система предотвращает наличие различных версий одних и тех же элементов данных, доступных пользователям, на различных стадиях обновления;
13) секретность — несанкционированный доступ к данным невозможен. Ограничение доступа к одним и тем же данным для различного их использования может осуществляться различными способами;
14) защита от искажения и уничтожения — данные должны быть защищены от сбоев, катастрофических и криминальных ситуаций, некомпетентного или злонамеренного обращения к ним лиц, которые могут ошибочно обновить их. [9].
2.1.3 Основные концепции реляционных баз данных
Теория реляционной базы данных разработана в начале 70-х годов доктором Э.Ф. Коддом на основе математической теории отношений. Предложенные им идеи оказали большое влияние на технологию баз данных во всех ее аспектах.
Реляционная база данных представляет собой совокупность таблиц, связанных между собой определенными отношениями и предназначенных для хранения данных. Основными понятиями в этой теории являются таблица, отношение, строка, столбец, ключи.
Таблица реляционной базы данных состоит из множества строк и столбцов и имеет уникальное имя в базе данных. База данных содержит множество таблиц, связь между которыми устанавливается с помощью совпадающих полей. Каждая строка таблицы содержит данные об одном объекте и называется записью. Все записи имеют одинаковую структуру — они состоят из полей, в которых хранятся атрибуты (свойства) объекта. Строки отношения (таблиц) называются кортежами. Такие таблицы обладают следующими свойствами:
1) каждый элемент таблицы представляет собой один элемент данных, повторяющиеся группы отсутствуют;
2) все столбцы в таблице однородные, то есть элементы столбца имеют одинаковую природу;
3) в таблице нет двух одинаковых строк;
4) порядок строк в таблице произвольный.
Количество атрибутов в отношении называется степенью или рангом отношения. Каждая таблица должна иметь один или несколько столбцов (атрибутов), которые однозначно идентифицируют каждый объект в таблице, то есть позволяют четко отличить один объект от другого. Такие столбцы образуют первичный ключ, и если столбцов несколько, то говорят, что первичный ключ является составным. Поле, предоставляющее первичный ключ или являющееся частью первичного ключа, называется ключевым полем. В реляционной базе данных очень важным является понятие связи между таблицами. Связь — это логическое отношение между объектами, представленными таблицами. Связь между записями двух таблиц основана обычно на совпадении значений атрибутов, по которым эта связь устанавливается. Имеются четыре типа связей между таблицами: один-к- одному, один-ко-многим, много-к-одному, много-ко-многим.
Отношение один-к-одному означает, что каждая запись одной таблицы соответствует только одной записи в другой таблице.
Наиболее часто встречающимся типом отношений в базе данных является один-ко-многим. Данное отношение означает, что каждой записи одной таблице соответствует несколько записей в другой таблице.
Отношение много-к-одному аналогично рассмотренному ранее типу один-ко-многим.
Отношение много-ко-многим возникает между двумя таблицами в тех случаях, когда:
1) одна запись из первой таблице может быть связана более чем с одной записью из второй таблицы;
2) одна запись из второй таблице может быть связана более чем с одной записью из первой таблицы.
Преимуществами реляционной модели БД являются простота логической модели (таблицы привычны для представления информации); гибкость системы защиты (для каждого отношения может быть задана правомерность доступа); независимость данных; возможность построения простого языка манипулирования данными с помощью математически строгой теории реляционной алгебры (алгебры отношений). К настоящему времени реляционные модели баз данных получили наибольшее распространение в современных информационных технологиях.
Множество отношений и операций над данными образует реляционную алгебру. Все множество операций реляционной алгебры разделено на две группы:
1) теоретико-множественные (объединение, пересечение, разность, расширенное декартовое произведение);
2) специальные.
Реляционная модель БД имеет дело с тремя аспектами данных: со структурой данных, с целостностью данных и с манипулированием данными. Под структурой понимается логическая организация данных в БД, под целостностью данных — безошибочность и точность информации, хранящейся в БД, под манипулированием данными — действия, совершаемые над данными в БД. Эти три аспекта отражают и основные процедуры процесса накопления данных (хранение, актуализацию и извлечение) [7].
2.1.4 Нормализация баз данных
Центральной задачей проектирования базы данных АИС — определение качества отношений и их атрибутивного состава. Группировка атрибутов в отношения допускает множество различных вариантов решений. Рациональные варианты группировки должны учитывать следующие требования:
1) множество отношений должно обеспечивать минимальную избыточность представления информации;
2) корректировка отношений не должна приводить к двусмысленности или потере информации;
3) перестройка набора отношений при добавлении в базу данных новых атрибутов должна быть минимальной.
Нормализация данных представляет собой процесс преобразования отношений путем ликвидации повторяющихся групп и иных противоречий с целью приведения таблиц к виду, позволяющему осуществить непротиворечивое и корректное редактирование данных.
Ограничения на значения, хранимые в реляционной базе данных, достаточно многочисленны. Соблюдение этих ограничений в конкретных отношениях связано с наличием так называемых нормальных форм. Процесс преобразования отношений базы данных к той или иной нормальной форме называется нормализацией отношений. Нормальные формы нумеруются последовательно от первой до пятой, и чем больше номер нормальной формы, тем больше ограничений на хранимые значения должно соблюдаться в соответствующем отношении. Окончательная цель нормализации — получение такого проекта базы данных, в котором исключается избыточность информации.
Основными свойствами нормальных форм являются:
1) каждая следующая нормальная форма в некотором смысле улучшает свойства предыдущей нормальной формы;
2) при переходе к следующей нормальной форме свойства предыдущих сохраняются.
В теории реляционных баз данных обычно выделяют следующие последовательные нормальные формы (НФ): 1НФ; 2НФ; 3НФ; 4НФ;5НФ. Отношения находятся в некоторой нормальной форме, если оно удовлетворяет свойственному данной форме набору ограничений.
Первая нормальная форма.
Первая нормальная форма требует, чтобы на любом пересечении строки и столбца находилось единственное значение, которое должно быть атомарным. Данное требование является базовым требованием классической реляционной базы данных, поэтому любая реляционная таблица по определению уже находится в 1 нормальной форме.
Вторая нормальная форма.
Отношения находятся во 2НФ в том случае, когда это отношение находится в 1НФ, и не содержит неполных функциональных зависимостей. Представление таблицы во второй нормальной форме требует, чтобы все столбцы, не являющиеся первичными ключами (столбцы, описывающие объект, но однозначно не идентифицирующие его), зависели от всего первичного ключа, а не от его отдельных компонентов.
Третья нормальная форма.
Отношение находится в третьей нормальной форме тогда, когда оно находится во 2НФ и ни один не ключевой столбец не зависит от другого не ключевого столбца. Любой не ключевой столбец должен зависеть только от столбца первичного ключа.
Чтоб перейти от 2НФ к 3НФ необходимо:
1) определить все поля (или группу полей), от которых зависят другие поля;
2) создать новую таблицу для каждого такого поля (или группы полей) и группы зависящих от него полей и переместить их в эту таблицу. Поле (или группа полей) от которых зависят все перемещаемые поля, станет при этом первичным ключом новой таблицы;
3) удалить перемещенные поля из исходной таблицы, оставив лишь те из них, которые станут внешним ключом.
Четвертая и пятая нормальные формы.
Четвертая нормальная форма запрещает независимые отношения типа один-ко-многим между ключевыми и не ключевыми столбцами. Пятая нормальная форма доводит весь процесс нормализации до логического конца, разбивая таблицы на минимально возможные части для устранения в них всей избыточности данных. Нормализованные таким образом таблицы обычно содержат минимальное количество информации, помимо первичного ключа. Таким образом, любой фрагмент не ключевых данных (данных, не являющихся первичным или внешним ключом) встречается в базе данных только один раз, и не возникает никаких проблем при их обновлении. Однако, поскольку каждая таблица в пятой нормальной форме имеет минимальное число столбцов, то в них должны дублироваться одни и те же ключи, обеспечивая возможности для объединения таблиц и получения полезной информации [10].
2.2 Проектирование приложения
2.2.1 Выбор системы проектирования и реализации
Для технической реализации вышеуказанных задач с учетом поставленных требований была выбрана система управления базами данных Microsoft Access.
Данная СУБД была выбрана по следующим причинам:
- простота средств реализации,
- легкость освоения инструментарием разработчика (VBA),
- наглядность визуализации информации.
Базы данных созданные с помощью системы управления базами данных Microsoft Access полностью реализую реляционную модель построения данных.
Связи между таблицами можно разбить на четыре базовых реляционных типа с отношениями:
- один-к-одному;
- один-ко-многим;
- многие-к-одному;
- многие-ко-многим.
Структура организации таблиц позволяет создание первичных и внешних ключей. Имеется возможность изменения типа внутренних объединений для связанных таблиц.
Также Microsoft Access предоставляет большое количество внутренних средств по оптимизации работы проектируемого приложения. К ним относятся:
- загрузка модулей по требованию;
- оптимизация дерева вызовов;
- использование файлов MDE;
- автоматическая поддержка компилированного состояния;
- использование библиотек Windows API;
- индивидуальная настройка системы;
- эффективное использование индексов;
- встроенный оптимизатор запросов.
Применение пакета Microsoft ADT (расширенные средства разработчика) вводит новый уровень визуализации данных, за счет таких элементов, как Tree View, Tab Control и других [8].
В качестве средства реализации выбрана система программирования Delphi. Как любая подобная система, Delphi предназначена для разработки программ и имеет две характерные особенности: создаваемые с её помощью программы могут работать не только под управлением Windows, а сама она относится к классу инструментальных средств ускоренной разработки программ (RAD).
Визуальное конструирование форм избавляет программиста от многих аспектов разработки интерфейса программы, так как Delphi автоматически готовит необходимые программные заготовки и соответствующий файл ресурсов. Программист использует специальное окно, которое называется окном формы, как прототип будущего окна программы и наполняет его компонентами, реализующими нужные интерфейсные свойства.
Библиотека визуальных компонентов предоставляет программисту огромное разнообразие созданных разработчиками Delphi программных заготовок, которые немедленно или после несложной настройки готовы к работе в рамках вашей программы. Компоненты характеризуются важным свойством: они включают в себя программный код и все необходимые для его работы данные, что избавляет программиста от рутинной работы по «изобретению велосипедов».
Также неоспоримым достоинством Delphi является наличие в составе среды библиотеки dbExpress которая в настоящее время является основным механизмом доступа к серверам SQL. Данная библиотека имеет в своём составе множество компонентов, облегчающих работу работы с базами данных.
Мощность и гибкость языка программирования — безусловное достоинство Delphi, выгодно отличающее эту систему программирования от других инструментов RAD.
От Visual Basic язык Delphi отличают строгая типизированность, позволяющая компилятору ещё на этапе компиляции обнаружить многие ошибки, а также средства работы с указателями.
Если по каким-либо причинам возможности Delphi кажутся недостаточными, вы можете программировать на Ассемблере, который органично вплетён в Delphi.
Во всех случаях Delphi имеет самый быстрый среди продуктов подобного рода оптимизирующий компилятор, позволяющий создавать быстрые и относительно компактные программы.
Глава 3. Разработка ИС учета договоров на предприятии
3.1 Общее описание БД реализованной системы
3.1.1 Шаги проектирования БД
Проектирование БД — это одна из сложных задач, которая связана с созданием ИС. Проект базы данных — это набор взаимосвязанных отношений, в котором определены все атрибуты, заданы первичные ключи отношений и заданы некоторые дополнительные свойства отношений, которые относятся к принципам поддержки целостности. Для создания эффективного приложения, работающего с информацией, хранящейся в базе данных, основное внимание должно уделяться проектированию структуры базы данных. Только хорошо организованная структура данных позволит:
1) сделать ввод информации простым и понятным для пользователя приложения;
2) быстро находить в базе данных требуемую информацию;
3) хранить данные в виде, который не приведет к чрезмерному разрастанию базы данных;
4) упростить разработку и сопровождение программного обеспечения.
5) Таким образом, основной целью процесса проектирования БД состоит в получении такого проекта, который будет удовлетворять требованиям:
a) корректность схемы БД;
b) обеспечение ограничений (на объемы внешней памяти и другие ресурсы вычислительной системы);
c) эффективность функционирования (соблюдение ограничений на время реакции системы на запрос и обновление данных);
d) защита данных (от аппаратных и программных сбоев и несанкционированного доступа);
e) простота и удобство эксплуатации;
f) гибкость, т.е. возможность развития и адаптации к изменениям предметной области и/или требований пользователей.
Процесс проектирования базы данных представляет собой последовательность переходов от неформального словесного описания информационной структуры предметной области к формальному описанию объектов предметной области в терминах некоторой модели. Выделяют следующие этапы проектирования.
Рисунок 3.1 — Этапы проектирования БД
В рамках системного анализа предметной области необходимо провести подробное словесное описание объектов предметной области и реальных связей, которые присутствуют между описываемыми объектами. Системный анализ должен заканчиваться подробным описанием информацией об объектах предметной области, сформулированных конкретных задач, с кратким описанием их решения, а также описание входных и выходных документов которые служат основанием для заполнения базы данных.
Инфологический (концептуальный) подход не представляет формальных способов моделирования реальности, но он закладывает основы методологии проектирования баз данных. Основными задачами инфологического (концептуального) проектирования являются определение предметной области (ПО) системы и формирование взгляда на ПО с позиций сообщества будущих пользователей БД, т.е. инфологической (концептуальной) модели ПО.
Рассмотрим основные подходы к созданию инфологической модели предметной области:
1) Функциональный подход к проектированию БД. Этот метод реализует принцип «от задач» и применяется тогда, когда известны функции некоторой группы лиц или комплекса задач, для обслуживания информационных потребностей которых создается рассматриваемая БД.
2) Предметный подход к проектированию БД. Этот метод применяется в тех случаях, когда у разработчиков есть четкое представление о самой ПО и о том, какую именно информацию они хотели бы хранить в БД, а структура запросов не определена.
3) Проектирование с использованием метода «сущность — связь». Метод «сущность — связь» является комбинацией двух предыдущих и обладает достоинствами обоих.
Этап инфологического проектирования начинается с моделирования ПО. Проектировщик разбивает ее на ряд локальных областей, каждая из которых включает в себя информацию, достаточную для обеспечения запросов отдельной группы будущих пользователей или решения отдельной задачи (подзадачи). Каждое локальное представление моделируется отдельно, затем они объединяются.
Выбор локального представления зависит от масштабов ПО. Обычно она разбивается на локальные области таким образом, чтобы каждая из них соответствовала отдельному внешнему приложению и содержала 6-7 сущностей.
Сущность — это объект, о котором в системе будет накапливаться информация. Сущности бывают как физически существующие (например, «Сотрудники» или «Автомобиль»), так и абстрактные (например, «Экзамен» или «Диагноз»).
Для сущностей различают тип сущности и экземпляр. Тип характеризуется именем и списком свойств, а экземпляр конкретными значениями свойств.
Типы сущностей можно классифицировать как родительские (сильные) и дочерние (слабые). Родительские сущности существуют сами по себе, а существование дочерних зависит от существования родительских. Например, читатель библиотеки — родительская сущность, а абонемент этого читателя — дочерняя, которая зависит от наличия соответствующего читателя. Дочерние сущности называются подчиненными, а родительские — базовыми.
Для каждой сущности выбираются свойства (атрибуты).
Различают:
1) Идентифицирующие и описательные атрибуты. Идентифицирующие атрибуты имеют уникальное значение для сущностей данного типа и являются потенциальными ключами. Они позволяют однозначно распознавать экземпляры сущности. Из потенциальных ключей выбирается один первичный ключ (ПК). В качестве ПК обычно выбирается потенциальный ключ, по которому чаще происходит обращение к экземплярам записи. Кроме того, ПК должен включать в свой состав минимально необходимое для идентификации количество атрибутов. Остальные атрибуты называются описательными и заключают в себе интересующие свойства сущности.
2) Составные и простые атрибуты. Простой атрибут состоит из одного компонента, его значение неделимо. Составной атрибут является комбинацией нескольких данных (например, ФИО или адрес). Решение о том, использовать составной атрибут или разбивать его на компоненты, зависит от характера его обработки и формата пользовательского представления этого атрибута.
3) Однозначные и многозначные атрибуты (могут иметь соответственно одно или несколько значений для каждого экземпляра сущности).
4) Основные и производные атрибуты. Значение основного атрибута не зависит от других атрибутов. Значение производного атрибута вычисляется на основе значений других атрибутов (например, возраст студента вычисляется на основе даты его рождения и текущей даты).
Выбор СУБД и других программных средств — является одним из важнейших моментов в разработке проекта БД, так как он влияет на весь процесс проектирования БД и реализацию ИС. При выборе СУБД разработчики руководствуются следующими критериями:
? тип модели данных, которую поддерживает данная СУБД, ее адекватность потребностям рассматриваемой предметной области;
? характеристики производительности системы;
? запас функциональных возможностей для дальнейшего развития ИС;
? степень оснащенности системы инструментарием для персонала администрирования данными;
? удобство и надежность СУБД в эксплуатации;
? стоимость СУБД и дополнительного программного обеспечения.
Логическое проектирование БД — на данном этапе разрабатывается логическая структура БД, соответствующая логической модели ПО. Проектирование схемы базы данных может быть выполнено двумя путями:
1) путем декомпозиции (разбиения) когда исходное множество отношений входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает) являющихся проекциями исходных отношений;
2) путем синтеза или компоновки из заданных исходных элементарных зависимостей между объектами предметной области.
Физическое проектирование БД — данный этап заключается в связывании логической структуры БД и физической среды хранения для наиболее эффективного размещения данных. Решается вопрос размещения хранимых данных в пространстве памяти, выбора эффективных методов доступа к различным компонентам «физической» БД. Результаты этого этапа документируются в форме схемы хранения на языке определения данных (DDL). Принятые на этом этапе решения оказывают определяющее влияние на производительность системы.
Одной их важнейших составляющих проекта базы данных является разработка средств защиты БД. Защита данных имеет два аспекта: защита от сбоев и защита от несанкционированного доступа. Для защиты от сбоев разрабатывается стратегия резервного копирования. Для защиты от несанкционированного доступа каждому пользователю доступ к данным предоставляется только в соответствии с его правами доступа [11].
3.1.2 Описание предметной области
В качестве предметной области выбрана строительная фирма ООО «Строй-Сервис» в г.Усть-Куте.
Данная БД предназначена для:
- учета контрагентов организации;
- учета товаров и услуг, потребляемых в ходе выполнения подрядных работ;
- учета заключенных договоров, работ по договору;
- составления графика оплаты по работам договора;
- составления графика потребления товаров и услуг по работам договора;
- заключения дополнительных соглашений к договору;
- составления графика оплаты и графика потребления товаров и услуг по дополнительному соглашению;
- ведения журнала платежей;
Формирования следующих выходных документов и отчетности:
- договор подряда;
- график работ и оплаты по договору;
- дополнительное соглашение;
- график работ и оплаты по дополнительному соглашению;
- полный список потребляемых товаров и услуг по договору;
- список платежей по договору;
- журнал платежей за заданный период времени;
- список заключенных договоров за заданный период времени;
- список контрагентов;
- справочник товаров и услуг.
Задачи ориентированы, прежде всего, на выполнение непосредственных функциональных обязанностей специалиста службы учета, директора организации, офис-менеджера.
3.1.3 Инфологическое проектирование
Инфологическая модель данных.
Посредством анализа предметной области выделены следующие сущности и их атрибуты.
Сущности:
1) «Договоры» (№договора; КонтрагентID; ДатаНач; ДатаКон; СтатусID; Сумма);
2) «ДопСоглашения» (№Соглашения; ДоговорID; РаботаID; Наименование; ДатаНач; ДатаКон; Выполнено; Описание);
3) «ЖурналПлатежей» (Счет№; СчетДата; Сумма; Назначение);
4) «Контрагенты» (ID; Наименование; Адрес; Телефоны; Реквизиты; ИНН; КПП; ВлицеКого);
5) «Оплата» (ID; РаботаID; ДатаАванс; ДатаОстаток; СуммаАванс; СуммаОстаток; ОплаченАванс; ОплаченОстаток);
6) «ОплатаДопСоглашение» (ID; ДопСоглашениеID; ДатаАванс; ДатаОстаток; СуммаАванс; СуммаОстаток; ОплаченАванс; ОплаченОстаток);
7) «Потребление» (РаботаID; ТоварУслугаID; Количество; Цена);
8) «ПотреблениеДопСоглашене» (ДопСоглашениеID; ТоварУслугаID; Количество; Цена);
9) «Работы» (Шифр; ДоговорID; Наименование; ДатаНач; ДатаКон; Выполнено; Описание);
10) «СтатусыДоговора» (ID; Статус);
11) «ТоварыУслуги» (Шифр; Наименование; Услуга; ЕдИзм; Цена).
Инфологическая модель применяется на втором этапе проектирования БД, то есть после словесного описания предметной области. Процесс проектирования длительный и требует обсуждений с заказчиком и со специалистами в предметной области. Инфологическая модель должна включать такое формализованное описание предметной области, которое легко будет «читаться» не только специалистами по БД. И это описание должно быть настолько емким, чтобы можно было оценить глубину и корректность проработки проекта БД, и конечно, оно не должно быть привязано к конкретной СУБД. Выбор СУБД — это отдельная задача, для корректного ее решения необходимо иметь проект, который не привязан ни к какой конкретной СУБД.
Цель инфологического моделирования — обеспечение наиболее естественных для человека способов сбора и представления той информации, которую предполагается хранить в создаваемой базе данных. Поэтому инфологическую модель данных пытаются строить по аналогии с естественным языком. Основными конструктивными элементами инфологических моделей являются сущности, связи между ними и их свойства (атрибуты).
Сущность — любой различимый объект (объект, который мы можем отличить от другого), информацию о котором необходимо хранить в базе данных. Необходимо различать такие понятия, как тип сущности и экземпляр сущности. Понятие тип сущности относится к набору однородных личностей, предметов, событий или идей, выступающих как целое. Экземпляр сущности относится к конкретной вещи в наборе.
Сущность имеет имя, уникальное в пределах модели. При этом имя сущности — это имя типа, а не конкретного экземпляра.
Сущность может быть расщеплена на два или более взаимоисключающих подтипов, каждый из которых включает общие атрибуты и/или связи. Эти общие атрибуты и/или связи явно определяются один раз на более высоком уровне. В подтипах могут определяться собственные атрибуты и/или связи.
Сущность, на основе которой определяются подтипы, называется супертипом. Подтипы должны образовывать полное множество, то есть любой экземпляр супертипа должен относиться к некоторому подтипу. Иногда для полноты множества надо определять дополнительный подтип, например, «Прочие».
Атрибут — поименованная характеристика сущности. Его наименование должно быть уникальным для конкретного типа сущности, но может быть одинаковым для различного типа сущностей. Атрибуты используются для определения того, какая информация должна быть собрана о сущности.
Ключ — минимальный набор атрибутов, по значениям которых можно однозначно найти требуемый экземпляр сущности. Минимальность означает, что исключение из набора любого атрибута не позволяет идентифицировать сущность по оставшимся.
Связь — ассоциирование двух или более сущностей. Если бы назначением базы данных было только хранение отдельных, не связанных между собой данных, то ее структура могла бы быть очень простой. Однако одно из основных требований к организации базы данных — это обеспечение возможности отыскания одних сущностей по значениям других, для чего необходимо установить между ними определенные связи. А так как в реальных базах данных нередко содержатся сотни или даже тысячи сущностей, то теоретически между ними может быть установлено более миллиона связей. Наличие такого множества связей и определяет сложность инфологических моделей.
Между сущностями могут быть установлены связи — бинарные ассоциации, показывающие, каким образом сущности соотносятся или взаимодействуют между собой. Связь может существовать между двумя разными сущностями или между сущностью и ей же самой (рекурсивная связь). Она показывает, как связаны экземпляры сущностей между собой. Если связь устанавливается между двумя сущностями, то она определяет взаимосвязь между экземплярами одной и другой сущности
Связи делятся на три типа по множественности: один-ко-одному (1:1), один-ко-многим (1:М), многие-ко-многим (М:М).
Связь один-ко-одному означает, что экземпляр одной сущности связан только с одним экземпляром другой сущности.
Связь один-ко-многим (1:М) означает, что один экземпляр сущности, расположенный слева по связи, может быть связан с несколькими экземплярами сущности, расположенными справа по связи.
Связь «многие-ко-многим (М:М) означает, что несколько экземпляров первой сущности могут быть связаны с несколькими экземплярами второй сущности, и наоборот. Между двумя сущностями может быть задано сколько угодно связей с разными смысловыми нагрузками.
Связь любого из этих типов может быть обязательной, если в данной связи должен участвовать каждый экземпляр сущности, необязательной — если не каждый экземпляр сущности должен участвовать в данной связи. При этом связь может быть обязательной с одной стороны и необязательной с другой стороны.
Проведем инфологическое проектирование базы данных учета договоров в строительной фирме.
Проблема представления семантики давно интересовала разработчиков, и в семидесятых годах было предложено несколько моделей данных, названных семантическими моделями. К ним можно отнести семантическую модель данных, предложенную Хаммером и Мак-Леоном, функциональную модель данных Шипмана, модель «сущность-связь», и ряд других моделей. В настоящий момент именно модель «сущность-связь» стала фактическим стандартом при инфологическом моделировании баз данных. Большинство современных CASE-средств содержат инструментальные средства для описания данных в формализме этой модели.
Для реализации базы данных выбрана МS Аccеss. Для доступа к БД используется АDО (ActiveX Data Object) Delphi.
3.1.4 Даталогическое проектирование
В реляционных БД даталогическое проектирование приводит к разработке схемы БД, то есть совокупности схем отношений, которые адекватно моделируют абстрактные объекты предметной области и семантические связи между этими объектами.
В результате выполнения этого этапа должны быть получены следующие результаты:
— описание концептуальной схемы БД в терминах выбранной СУБД;
— описание внешних моделей в терминах выбранной СУБД;
— описание декларативных правил поддержки целостности базы данных;
— разработка процедур поддержки семантической целостности базы данных.
Проектирование схемы БД может быть выполнено двумя путями:
— путём декомпозиции, когда исходное множество отношений, входящих в схему БД заменяется другим множеством отношений (число их при этом возрастает), являющихся проекциями исходных отношений;
— путём синтеза, то есть путём компоновки из заданных исходных элементарных зависимостей между объектами предметной области схемы БД.
Процесс проектирования с использованием декомпозиции представляет собой процесс последовательной нормализации схем отношений, при этом каждая последующая итерация соответствует нормальной форме более высокого уровня и обладает лучшими свойствами по сравнению с предыдущей. Каждой нормальной форме соответствует некоторый определённый набор ограничений, и отношение находится в некоторой нормальной форме, если удовлетворяет свойственному ей набору ограничений.
Отношение находится в первой нормальной форме тогда и только тогда, когда на пересечении каждого столбца и каждой строки находятся только элементарные значения атрибутов. Т.е. поля должны содержать неделимую информацию и в таблице должны отсутствовать повторяющиеся группы полей.
Текущие таблицы полностью соответствуют этим требованиям.
Отношение находится во второй нормальной форме тогда и только тогда, когда оно находится в первой нормальной форме и не содержит неполных функциональных зависимостей непервичных атрибутов от атрибутов первичного ключа. Т. е. любое не ключевое поле должно однозначно идентифицироваться ключевыми полями.
Рисунок 3.2 — Даталогическая модель
3.2 Общее описание разработанного приложения
3.2.1 Логическая структура приложения
Размещено на http://www./
Размещено на http://www./
Рисунок 3.3 — Структура приложения
Рисунок 3.4 — Окно главного меню
Основное меню, предназначено для запуска основных процедур программы и завершения работы с программой.
Пункт меню «Контрагенты» содержит сведения о подрядчиках с возможностью корректировки данных и, если необходимо, распечатки данных (рис 3.5).
Рисунок 3.5 — Контрагенты
Пункт меню «Товары и услуги» содержит сведения о предоставляемых услугах строительной фирмой ООО «Строй-Сервис» и сопутствующем товаре (рис.3.6).
Рисунок 3.6 — Товары и услуги
При нажатии на кнопку «Договоры» появляется следующее окно (рис. 3.7).
Рисунок 3.7 — Окно просмотра договоров
В окне просмотра договоров, пользователь может просматривать сведения о договорах, их статусе, дате заключения и выполнения (рис.3.8), а также, при нажатии на кнопку «Открыть», можно получить информацию о предмете договора, имеются ли дополнительные соглашения, сведения о потреблении товаров и услуг, сведения об оплате (рис.3.9).
Рисунок 3.8 — Просмотр договора по номеру
Рисунок 3.9 — Дополнительное соглашение
Кнопка «Журнал платежей», содержит информацию о платежах, поступивших на счет предприятия за оказание услуг (рис.3.10).
Рисунок 3.10 — Окно Журнал платежей
На рисунке 3.11 показаны дополнительные формы для просмотра потребления товаров и услуг по номеру договора и дополнительным соглашениям и суммы проплат.
Рисунок 3.11 — Дополнительные формы
Интерфейс программы реализован в Delphi, выходные документы генерируются в MS Word и MS Excel (рис.3.11).
1 Автоматизированные информационные технологии в экономике: учебник/ Под ред.проф.Г.А.Титоренко — М.:ЮНИТИ, 2007.-399с.
2 Теория экономических информационных систем: Учебник. А.И. Мишенин — М.: Финансы и статистика, 2006. — 240с.
3 Елисеев В. Ладыженский Г. Введение в Интранет. Системы Управления Базами Данных — М.- 2006.
4 Компьютерные системы и сети: Учебное пособие/ Под ред. В.П.Косарева и Л.В. Еремина. — М.: Финансы и статистика, 2005. — 464с.
5 Информационные системы: Учебник для вузов / В.Н.Петров.- СПб.: Питер, 2007. — 687с.
6 Томсон Л. Веллинг Л. Разработка web-приложений на PHP и MySQL- СПб.: ООО “ДиаСофтЮП”,2008. — 672с.
7 Бекаревич Ю.Б. Microsoft Access 2003. — СПб.: БХВ-Петербург, 2006. — 202с.
8 Самохина М.И., Работа с СУБД Microsoft Access: учебное пособие/ М.И. Самохина, Н.А.Барковская — Братск: ГОУ ВПО «Братский государственный университет», 2008. — 85с.
9 Проектирование информационных систем: Учебное пособие./ Н.Н.Заботина. — Братск: ГОУВПО «БрГТУ», — 2004. — Ч 2: 119с.
10 Дейт К.Дж.- Введение в системы баз данных.:Пер. с англ. — 6-еизд. — К.:Диалектика, 2007. — 784с.
11 Н. Н. Заботина Проектирование информационных систем. Часть 1. Методология функционального моделирования: Учебное пособие. — Братск: ГОУВПО «БрГУ», 2005. — 146с.
12 Н. Н. Заботина Проектирование информационных систем. Часть 2. Концептуальное моделирование базы данных: Учебное пособие. — Братск: ГОУВПО «БрГУ», 2004. — 119с.
13 Ким С.Г., Шелепова М.Ю. Delphi. Система визуального программирования: Учебное пособие.-Братск: ГОУ ВПО «БрГУ», 2005. — 129 с.
14 Хоменко А.Д., Гофман В.Э. Работа с базами данных в Delphi. — 3-е изд., перераб. и доп. — СПб.:БХВ-Петербург, 2005. — 640с.
15 Мотузко Ф.Я. Охрана труда. — М.: Высшая школа, 2006. — 336с.
16 Безопасность жизнедеятельности. /Под ред. Н.А. Белова — М.: Знание, 2000. — 364с.
17 Самгин Э.Б. Освещение рабочих мест. — М.: МИРЭА, 2002. — 186с.
18 Справочная книга для проектирования электрического освещения. / Под ред. Г.Б. Кнорринга. — Л.: Энергия, 2001.- 457с.
19 Борьба с шумом на производстве: Справочник / Е.Я. Юдин, Л.А. Борисов; Под общ. ред. Е.Я. Юдина — М.: Машиностроение, 2005. — 400с.
20 Зинченко В.П. Основы эргономики. — М.: МГУ, 2002. — 179с.
Приложение А
ДОГОВОР ПОДРЯДА
(С ИСПОЛЬЗОВАНИЕМ МАТЕРИАЛОВ ПОДРЯДЧИКА)
№23/12
г. Усть-Кут 12 февраля 2012 г.
ООО «Строй-Сервис», именуемый в дальнейшем «Заказчик», в лице Васильева Ивана Петровича, действующего на основании Устава, с одной стороны, и ООО «Сервис-Строй», именуемое в дальнейшем «Подрядчик», в лице Глебова Андрея Васильевича, действующего на основании Устава, с другой стороны, заключили настоящий договор о нижеследующем:
1. Предмет договора
1.1. Заказчик поручает, а Подрядчик обязуется выполнить работы, указанные в Приложении N1 к настоящему Договору.
1.2. Объем, вид и срок исполнения работ устанавливается сторонами в факсимильных сообщениях, телефонограммах и в дополнительных соглашениях в период действия договора.
1.3. Для выполнения работ, указанных в Приложении №1 к настоящему Договору Подрядчик использует собственное сырье и материалы. Стоимость сырья и материалов включается в цену работ, установленную настоящим Договором.
1.4. Подрядчик несет ответственность за качество сырья и материалов, используемых для выполнения работ по поручению Заказчика.
2. Стоимость работ и порядок расчетов
2.1. Стоимость работ устанавливается в Приложении №1, являющемся неотъемлемой частью настоящего Договора.
3. Порядок выполнения и сдачи-приемки работ
3.1. Заказчик имеет право присутствовать при выполнении работ, а также контролировать их выполнение.
3.2. Приемка выполненных работ осуществляется путем подписания акта сдачи-приемки работ и передачи сопроводительных документов на выполненные работы Заказчику.
3.3. Заказчик в течение 10 дней со дня получения акта сдачи-приемки работ и отчетных документов обязан направить Подрядчику подписанный акт сдачи-приемки выполненных или мотивированный отказ от приемки работ.
3.4. В случае прекращения работы по инициативе Заказчика последний в письменной форме уведомляет Подрядчика о причине и сроке прекращения действия Договора.
4. Ответственность сторон
4.1. Подрядчик несет ответственность за соответствие качества выполняемых работ установленным требованиям. В случае выполнения работ с качеством, не соответствующим требованиям, Подрядчик обязуется устранить недостатки.
4.2. За неисполнение или ненадлежащее исполнение обязательств по настоящему Договору стороны несут ответственность в соответствии с действующим законодательством. За нарушение сроков оплаты Подрядчик вправе взыскать с Заказчика неустойку в размере 1% за каждый день просрочки.
4.3. Ни одна из сторон настоящего Договора не несет ответственности перед другой стороной за невыполнение обязательств, обусловленное обстоятельствами, возникшими помимо воли и желания сторон и которые нельзя предвидеть или избежать, включая объявленную или фактическую войну, гражданские волнения, эпидемии, блокаду, землетрясения, наводнения, пожары и другие стихийные бедствия.
Документ, выданный соответствующим компетентным органом, является достаточным подтверждением наличия и продолжительности действия непреодолимой силы.
4.4. Сторона, которая не исполняет своего обязательства вследствие действия непреодолимой силы, должна немедленно известить другую сторону о препятствии и его влиянии на исполнение обязательств по Договору.
5. Порядок разрешения споров
5.1. Все споры и разногласия между сторонами, возникающие в период действия настоящего Договора разрешаются сторонами путем переговоров.
5.2. В случае не урегулирования споров и разногласий путем переговоров, спор подлежит передаче в суд в соответствии с действующим законодательством РФ.
5.3. Положения, не урегулированные настоящим Договором, регулируются положениями действующего законодательства РФ.
6. Прочие условия
6.1. Право собственности, а также права на использование результатов работы по настоящему договору в любой форме принадлежат Заказчику.
6.2. Условия настоящего Договора имеют одинаковую юридическую силу для Сторон и могут быть изменены по взаимному согласию с обязательным составлением письменного документа, который является неотъемлемой частью настоящего Договора.
6.3. Настоящий Договор составлен в 2-х экземплярах, имеющих одинаковую юридическую силу, по одному экземпляру для каждой из
Сторон.
7. Срок действия договора
начало: 12 февраля 2012 г.
окончание: 12 июня 2012 г.
8. Адреса и платежные реквизиты сторон
Заказчик:
ООО «Сервис-Строй»
г. Усть-Кут, ул. Яблочная, 54
ЗАО «БИНБАНК», р/с 4070281030089938475, к/с 3030181050000746537
ИНН 9847564583
КПП 986475643
Подрядчик:
ООО «Строй-Сервис»
665780, г. Усть-Кут, ул .Каракозова, д.34665780, г. Усть-Кут, ул .Каракозова, д.34
ОАО «Сбербанк». р/с 4070281050056000589, к/c 3010181030000589617ОАО «Сбербанк». р/с 4070281050056000589, к/c 3010181030000589617
ИНН 123454567845123454567845
КПП 345546776345546776
Подписи сторон:
Заказчик
Подрядчик
Приложение Б
Размещено на
