1.3. Анализ существующего программного обеспечения
Существуют различные способы организации данных. Так, в разное время использовались базы данных, основанные на инвертированных списках, иерархические, сетевые структуры данных и т. д.
В 50-х гг. прошлого столетия появились первые компьютеры, и информацию стали переносить на магнитные носители. Первоначальный способ ее хранения не позволял наблюдать за текущими изменениями, но в конце 60-х гг. началось использование систем баз данных с оперативными доступом к актуальной информации.
По сути, с этого времени и появились базы данных в современном понимании. Такие базы данных также хранились на магнитных носителях, которые обеспечивали доступ к любому элементу данных за доли секунды. Программное обеспечение позволяло считывать одновременно несколько записей, изменять их и затем возвращать новые значения.
Однако быстро выяснилось, что такой способ хранения данных неудобен. Приложениям часто требуется связать две или более записи, в том числе содержащие разнородную информацию. Подобные проблемы пробовали решать путем применения иерархической модели данных, которая предполагала группировку одних записей под другими, на более низком уровне иерархии. Но по мере развития программ-приложений выяснилось, что разным пользователям желательно иметь разные представления данных, выражаемые в виде разных иерархий, что приводило к необходимости хранения избыточных данных.
Эту проблему пытались решить с помощью сетевой модели данных, в которой каждая запись хранится в одном экземпляре и связывается с набором других записей. Например, все данные по конкретной метеостанции связываются с этой станцией. Программа может попросить СУБД перебрать эти данные. Такая модель была широко распространена к началу 80-х гг., но по ряду причин оказалась неудобной, в основном для разработчиков, а не для конечных пользователей.
В качестве альтернативы выступила реляционная модель, наиболее распространенная на сегодняшний день модель базы данных.
На смену реляционной модели может прийти объектная, построенная на основе прямых адресных отсылок, хотя на сегодняшний день для большинства рядовых пользователей она представляет скорее теоретический интерес. Продекларированные на сегодняшний день преимущества объектной модели данных сводятся к возможности:
описания в рамках единого информационного поля объектов, имеющих разнородную внутреннюю структуру и состав элементов;
установления сложных многоуровневых отношений между информационными объектами;
вложения объектов друг в друга, выделения общих свойств объектов на верхних уровнях и учета индивидуальных качеств и свойств объектов на нижних уровнях иерархии;
хранения в едином банке данных структурированной информации и неформализованных данных.
В дальнейшем будем рассматривать только реляционные базы данных, поскольку именно эта модель данных предполагается использовать для создания автоматизированной информационной системы по работе с клиентами на предприятии Ессентукского филиала ОАО «ЮТК».
В реляционных база данных используется один из самых естественных способов представления данных - двухмерная таблица. С другой стороны, и связи между данными также могут быть представлены в виде двухмерных таблиц. Так, например, связь между двумя таблицами можно установить, записывая в один из столбцов третьей, связующей таблицы, номера записей в первой таблице, а в другой столбец — соответствующие им номера записей во второй таблице.
Таким образом, любой набор данных может быть представлен в виде плоских таблиц. Каждая таблица связи обладает следующими свойствами:
все элементы столбца имеют одинаковый тип данных;
столбцам присвоены уникальные имена;
в таблице нет двух одинаковых строк;
порядок расположения строк и столбцов в таблице не имеет значения.
Таблица такого рода называется отношением. База данных, построенная с помощью отношений, называется реляционной базой данных. Принципиальное отличие реляционной модели от сетевых и иерархических состоит в том, что вторые используют связь по структуре, а первая — по значению. Именно поэтому реляционная технология значительно упрощает задачу проектирования баз данных.
Итак, современные электронные базы данных чаще всего организованы в виде таблицы, и в настоящее время, как правило, используются реляционные базы данных, представляющие собой несколько взаимосвязанных таблиц. В понятие базы данных обязательным элементом входит описание правил этой взаимосвязи.
Независимо от того, сколько таблиц входит в базу данных, каждая строка любой таблицы содержит данные об одном объекте (человеке, техническом устройстве, документе и т. д.), а столбцы содержат различные характеристики этих объектов (названия, адреса, даты и т. д.). Строки таблицы принято называть записями, а столбцы — полями записей. В полях записей содержатся атрибуты объектов записей. Все записи имеют одинаковые поля, содержащие разные значения атрибутов. Каждое поле записи имеет строго определенный тип данных — текст, число, дата и т. п.
Для того чтобы таблицы можно было связать между собой, используют ключевые поля. Так называют одно или несколько полей, значение которого (или комбинация значений которых) однозначно определяет каждую запись таблицы, делает эту запись уникальной. Такие поля позволяют не только связать между собой разные таблицы, но и выполнять быстрый поиск данных для представления их в запросе, форме на экране или отчете на принтере. Ключ, состоящий из нескольких полей, называют составным.
Связи между таблицами бывают трех типов: «один к одному», «один ко многим» или «многие ко многим». Если мы составляем список сотрудников, то отношение между конкретным сотрудником и его адресом — «один к одному». А название отдела по отношению к списку сотрудников — «один ко многим», так как в одном отделе работает много (больше одного) сотрудников. А если сопоставить список преподавателей вуза со списком учебных дисциплин, которые в вузе преподаются, придется использовать связь типа «многие ко многим»: одну дисциплину могут преподавать разные преподаватели, и в то же время один преподаватель может читать разные дисциплины.
При организации связи типа «один ко многим» таблицу «один» принято называть главной, а таблицу «многие» — подчиненной. Ключ главной таблицы называют первичным, а подчиненной — внешним.
Любую таблицу реляционной базы данных можно назвать отношением, так как в таблицах с данными также реализованы связи между атрибутами записей типа «один к одному».
Для ускорения поиска и сортировки данных принято использовать индексированные поля. Для этих полей создается упорядоченный список значений, или индексов, который содержит ссылки на нужные записи. Например, если требуется отобрать записи по какой-либо метеостанции из таблицы, содержащей данные по нескольким станциям, удобно присвоить каждой свой индекс (номер, код) и в таблице из двух столбцов сопоставить этот индекс номерам записей. Тогда при отборе данных, например, по одной из станций, программе не потребуется «просматривать» все атрибуты всех записей, а достаточно будет только отобрать данные по коду нужной станции, используя ссылки на записи из такой таблицы.
Для работы с данными используются программные пакеты, которые называют системами управления базами данных (СУБД). Используя такие программы, можно создавать структуру базы данных, то есть, во-первых, таблицы, в которых каждый столбец хранит данные заранее определенного типа, и, во-вторых, правила связи между этими таблицами. Кроме того, СУБД позволяет выполнять следующие операции с данными (записями):
добавление записей в таблицы;
изменение или обновление некоторых полей;
удаление записей;
поиск записей, отвечающих некоторому условию, определенному пользователем.
Важной особенностью систем управления реляционными базами данных является обеспечение целостности данных. Оно означает поддержку некоторых правил при использовании связей между таблицами. Для того чтобы установить такую проверку, связанные поля таблиц должны иметь одинаковый тип данных, а связанное иоле главной таблицы должно являться ключевым или хотя бы иметь уникальный индекс. Целостность данных подразумевает, что:
в связанное поле подчиненной таблицы невозможно ввести атрибут, отсутствующий в главной таблице;
невозможно удалить атрибут записи главной таблицы, если имеются связанные записи в подчиненной таблице;
невозможно изменить значение ключевого поля главной таблицы, если с ним связаны записи в подчиненной.
Операции с данными обычно выполняют с помощью специального стандартного языка запросов — SQL (Structured Query Language — Структурированный язык запросов). Существуют различные пакеты для работы с данными — dBASE,FoxPro, Oracle и другие. Все они поддерживают язык SQL. СУБД, входящая в пакет MS Office, MS Access позволяет большинство операций с данными выполнять методом визуального конструирования запросов к базе данных. При этом запрос на языке SQL генерируется самой программой. Отметим, что такими возможностями обладает не только MS Access, но и многие другие СУБД, например, МS SQL Server, ориентированная на архитектуру клиент-сервер и которая благодаря постоянному совершенствованию и расширению своих возможностей приобретает все большую популярность у разработчиков.
В пакете МS SQL Server 2005 впервые появилась утилита SQL Server Management Studio, позволившая значительно упростить работу с пакетом. SQL Server Management Studio представляет собой утилиту обеспечивающую альтернативный графический интерфейс для управления любыми продуктами, которые входят в состав SQL Server 2005. Это следующие службы и возможности:
ядро SQL Server 2005 для управления базами данных;
Analysis server — служба по управлению OLAP-базами данных;
Integrajjon service — служба для преобразования данных между различными источниками;
Reporting service — служба, отвечающая за построение отчетов, а также позволяющая управлять ими и доставлять клиенту;
Notification service — служба, позволяющая уведомлять пользователей, посылая сообщения на различные устройства;
управление репликацией;
управление SQL Server Mobile Edition.
Основным достоинством SQL Server Management StuStudio является интеграция множества возможностей, представленных несколькими утилитами в SQL Server 2000. Кроме того, эта утилита поддерживает и новые возможности, например управление Notification-службой.
В SQL Server 2005 существует новый тип данных — XML. Этот тип позволяет хранить данные в формате XML не в виде строки, а непосредственно в формате XML. SQL Server 2005 поддерживает индексацию по столбцам этого типа. Кроме того, программист может использовать язык XQuery, чтобы обращаться к данным, хранимым в XML-ячейках. При этом программисту нет необходимости выбирать данные из SQL Server, а затем их обрабатывать — обработку можно делать прямо в запросе, выбирая только нужные данные.
В SQL Server для манипулирования данными используется язык запросов Transact-SQL (T-SQL), который является расширенной и дополненной компанией Microsoft версией языка SQL. Несмотря на наличие в SQL Server 2005 поддержки CLR, язык программирования Transact-SQL является основным при работе всех типов пользователей, а также при реализации любых видов сценариев.
Основные количественные показатели системы SQL Server доказывают возможность ее широкого использования при создании групповых и корпоративных баз данных: [6]
количество поддерживаемых баз данных - 32767;
максимальный размер базы данных - 1048516 терабайт;
максимальное число таблиц, определяемых в одной базе данных - 2 миллиарда;
максимальное количество столбцов в одной таблице – 1024;
максимальное число столбцов, которые можно определить в одном SQL-запросе – 32;
максимальное количество строк - неограниченно (определяется ресурсами сервера);
максимальное количество индексов для каждой таблицы – 250.
Все эти новые возможности делают Microsoft SQL Server все более популярным и широко используемым программным продуктом при создании средних и крупных групповых и корпоративных баз данных выполненных в архитектуре «клиент-сервер», спрос на которые в настоящее время постоянно растет.
- Содержание
- Введение
- 1. Аналитическая часть
- 1.1. Анализ предприятия
- 1.1.1. Характеристика предприятия и его деятельности
- 1.1.2. Программная и техническая архитектура ис на предприятии, использование их функциональных возможностей.
- Обеспечение информационной безопасности
- 1.1.4. Структурно-функциональная диаграмма деятельности предприятия по обслуживанию клиентов
- 1) Обращения на право доступа к телефонной сети или к сети передачи данных и телематических служб, требующих проверки наличия технической возможности
- 1.1) Предоставление доступа к услугам связи при наличии технической возможности доступа к телефонной сети, к сети передачи данных и телематических служб
- 1.2) Отсутствие технической возможности предоставления доступа к услуге, подготовка и выдача технических условий
- 2) Обработка запросов, не требующих проверки наличия технической возможности (замена номера и т.П.)
- 3) Порядок взаимодействия при приостановлении доступа к услугам при наличии дебиторской задолженности
- 4) Организация работ по учету заявлений о неисправности телефонной связи и радиоточки, поступающих от абонентов
- 5) Работа с обращениями пользователей
- 6) Личный прием граждан
- 7) Порядок взаимодействия при работе с операторами связи. Рассмотрение поступающих обращений
- 7.1) Взаимодействие сторон в случае наличия технической возможности
- 7.2) Взаимодействие сторон в случае отсутствия технической возможности и необходимости подготовки технических условий
- 8) Порядок взаимодействия сторон при рассмотрении обращений пользователей о предоставлении услуг связи посредством волс
- 1.2. Характеристика комплекса задач, задачи и обоснование необходимости автоматизации
- 1.2.1. Выбор комплекса задач автоматизации
- 1.2.2. Сущность задачи и предметная технология её решения
- 1.3. Анализ существующего программного обеспечения
- 1.4. Обоснование проектных решений
- 1.4.1. Обоснование проектных решений по техническому обеспечению проекта
- 1.4.2. Обоснование проектных решений по информационному обеспечению
- 1.4.3. Обоснование проектных решений по программному обеспечению проекта
- 2. Проектная часть
- 2.1. Информационное обеспечение задачи
- 2.1.1. Информационная модель и её описание. Построение модели информационной системы
- 2.1.2. Организация доступа к данным
- 2.2. Программное обеспечение задачи
- 2.2.1. Создание базы данных
- 2.2.2. Проектирование пользовательского интерфейса
- 2.2.3. Разработка программных модулей
- 2.2.4. Структура программных модулей
- 3. Обоснование экономической эффективности проекта
- 3.1. Расчет трудоемкости разработки
- 3.2. Определение себестоимости разработки
- 3.3. Определение экономического эффекта от внедрения
- 3.4. Определение срока окупаемости разработки
- 4.1. Эргономический анализ рабочего места оператора эвм
- 4.2. Организация рабочего места
- 4.3. Обеспечение рационального освещения рабочего места
- 4.4. Электробезопасность
- 4.5. Обеспечение пожарной безопасности
- Заключение
- Список сокращений
- Список использованных источников