Автоматизация работы служащего на примере АО "Казпочта"

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

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

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

- прием и вручение внутренних и международных почтовых отправлений;

- прием и оплату переводов;

- прием, доставку и учет подписки на

- периодическую печать;

- продажу периодических изданий,

- товаров народного потребления,

- товаров почты;

- прием телеграмм;

- выплата пенсий, пособий, стипендий,

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

- прием платежей от населения;

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

- обменные операци и с валютой;

- регистрация внутрихозяйственных операций.

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

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

В АО «Казпочта» банковская система Colvir является основной компьютерной программой работы всего общества. Однако и у этой программы и ее внедрением есть определенные сложности. Одна из них решение удаленных подразделений РУПС, СОПС (районных, сельских узлов почтовой связи). Но решение этой проблемы уже практически выполнено.

3. Мероприятия по повышению эффективности использования информационных систем в АО «Казпочта»

3.1 Описание предлагаемых мероприятий

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

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

Целями создания ИС является:

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

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

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

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

- усовершенствование системы документооборота;

- сокращение сроков формирования и обработки информации.

В соответствии с поставленной целью критериями эффективности создания ИС могут служить:

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

- снижение выдачи недостоверных данных (описок), устранение дублирования данных;

- повышение производительности труда;

Критериями выбора технических средств являются:

- надежность функционирования системы;

- функциональная полнота системы;

- быстродействие;

- минимизация затрат на стоимость.

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

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

- экономическую целесообразность ;

- финансовые возможности предприятия;

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

Всем вышеперечисленным требованиям в наибольшей мере отвечает учёт. Им присущи :

- низкая оперативность;

- большая трудоёмкость;

- низкая скорость и достоверность передачи данных;

- высокая возможность ошибок.

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

Разрабатываемый продукт должен удовлетворять ниже перечисленным требованиям:

- обеспечивать надёжное хранение информации;

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

-формировать отчеты;

- не требовать огромных ресурсов.

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

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

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

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

Первые попытки всерьез реформировать жизнь компаний с помощью компьютеров относятся еще к 1940-м - 1950-м годам. 1960-е - 1970-е запомнились идеей завода-автомата, активным развитием автоматических систем управления (АСУ), систем поддержки принятия решений (СППР), АСУТП (Автоматизированные системы управления технологическими процессами), САПР (системы автоматизированного проектирования) и др. Эти разработки нормально автоматизировали свои участки, но ни о каком единстве данных в пределах корпорации речь не могла идти. Так закладывалась традиция так называемой лоскутной автоматизации.

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

Примерно в то же время на Западе стала завоевывать себе дорогу идея единой системы управления данными в рамках организации. Первыми системами такого рода в 1970-е годы стали MRP (Material Requirements Planning - планирование технических требований к материальным ресурсам). Реальные функции соответствовали названию - планирование необходимых исходных материалов для производства.

Следующей стадией стали MRP-II (Manufacturing Resource Planning) - планирование производственных ресурсов. Это уже означало некоторую глобализацию подхода, управление производством как таковым интегрировалось с управлением закупками необходимых ресурсов, использованием трудозатрат, производственных мощностей и т.д.

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

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

Нам представляется, что речь идет всего лишь о придании ERP-системам CRM-функциональности (CRM - Customer Relationship Management - управление отношениями с клиентами).

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

Перспективы ERP

Безусловно, не следует считать внедрение корпоративных систем панацеей от всех бед предприятия, но не вызывает сомнений все большее увеличение их роли в мировой экономике. Быстрое развитие информационных технологий и систем в последние годы сделали внедрение корпоративных информационных систем высокой степени интеграции уделом не только громадных корпораций. Резко уменьшились стоимость и сроки внедрения новейших из таких систем. Достаточно напомнить, что по данным International Data Corporation (ШС), 58% компаний всего мира выделили в бюджете на 2000 г. суммы для покупки и/или обновления ERP - и CRM-систем, а к 2004 году, по данным той же аналитической группы, объем мирового рынка этих систем составит 24,8 миллиарда долларов.

Существенную роль должны сыграть ERP-системы и в развитии отечественной экономики.

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

Именно единые системы хранения и использования информации должны помочь отечественным предприятиям повысить эффективность управления и конкурентоспособность как на отечественном, так и на международном рынке. Все КИС можно разделить на системы электронного документооборота и на системы класса ERP (Enterprise Resource Planing) - планирование ресурсов предприятия. Системы электронного документооборота бывают локальными и финансово-управленческими. ERP-системы, в свою очередь делятся на средние интегрированные и крупные интегрированные.

Локальные системы (системы для малого бизнеса)

Данные системы предназначены для ведения учета по одному или нескольким направлениям (бухгалтерия, склады, сбыт, учет кадров и т. д.). Системы данной группы подходят практически любому предприятию, которому необходимы управление финансовыми потоками и автоматизация учетных функций. Подобные системы практически универсальны и, как правило, различаются они лишь интерфейсом. Часто в качестве готового решения может выступать даже коробочный продукт с самостоятельной установкой его на персональный компьютер. К потребителям локальных систем, в основном, относятся малые предприятия, а также торговые и дистрибьюторские компании. На российском рынке представлено более сотни таких систем. Наиболее известные - 1С, Альфа, БЭСТ, Инотек, Монополия, Флагман. Стоимость локальных систем, как правило, составляет от 5 до 50 тыс.долл.

Финансово-управленческие системы

Данные системы интегрируют деятельность предприятий и предназначены для учета и управления бизнес-процессами непроизводственных компаний. Несмотря на то, что финансово-управленческие системы, также как и локальные, часто бывают универсальными, в силу гораздо большей функциональности в них может проявляться отражение специфики деятельности конкретной компании. Часть финансово-управленческих систем тяготеет в сторону средних интегрированных систем (см. ниже), часть является чисто финансово-управленческими. К первым относятся Concorde XAL, SCALA, БОСС, Галактика, Парус, NS-2000, ко вторым - Exact, Hansa, Platinum SQL, ACCPAC, EFAS, Solomon IV, SunSystems. Стоимость финансово-управленческих систем составляет от 50 до 200 с лишним тыс. долл.

Средние интегрированные системы

Эти системы предназначены для управления производственным предприятием и интегрированного планирования производственного процесса. При этом учетные функции в таких системах, несмотря на глубокую проработку, играют вспомогательную роль, и часто невозможно выделить модуль бухгалтерского учета, так как информация в бухгалтерию автоматически поступает из других модулей. Ядром средних интегрированных систем является цепочка оперативного планирования сбыт - производство - закупки, при этом подразделения предприятия (бухгалтерия, финансы, маркетинг и другие) строят свою деятельность, основываясь на данных, полученных от этой цепочки. Такие системы покрывают потребности подразделений и полностью интегрируют производственное предприятие. Это требует значительных усилий сотрудников предприятия, поставщика программного обеспечения или консалтинговой компании, осуществляющей внедрение. Поэтому эти системы значительно более сложные в установке, и цикл внедрения может занимать от 6 до 9 месяцев. Для достижения соответствующего успеха производственное предприятие должно выступать как хорошо отлаженный механизм, так как требования, предъявляемые к средним интегрированным системам, гораздо более жесткие, чем к финансово-управленческим. К средним интегрированным системам относятся BPCS, СА-PRMS, Max, MFG/Pro, SyteLine, Renaissance, Axapta. Стоимость таких систем составляет до 500 тыс. долл.

Крупные интегрированные системы

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

Предоставляют полный комплекс возможностей, включая управление сложными финансовыми потоками, управление производством, глобальное планирование и бюджетирование и т.д. Следует заметить, что большинство имеющихся функций присущи и средним интегрированным системам и даже финансово-управленческим (за исключением производственных модулей), однако степень проработки у них несколько слабее. К крупным интегрированным системам относятся BaaN, JD Edwards, Oracle, SAP R/3.

3.2 Разработка АРМ «Автоматизация работы почтового служащего» для АО «Казпочта»

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

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

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

Используют взаимосвязи "один к одному", "один ко многим" и "многие ко многим". "Один к одному" - это взаимно однозначное соответствие, которое устанавливается между одним объектом и одним атрибутом. "Один ко многим" - это соответствие между одним объектом и многими атрибутами. "Многие ко многим" - это соответствие между многими объектами и многими атрибутами. [10, 11, 12].

Рассмотрим эти модели данных более подробно.

Иерархическая модель данных.

ИМД основана на понятии деревьев, состоящих из вершин и ребер. Вершине дерева ставится в соответствие совокупности атрибутов данных, характеризующих некоторый объект. Вершины и ребра дерева как бы образуют иерархическую древовидную структуру, состоящую из n уровней.

Первую вершину называют корневой вершиной. Он удовлетворяет условиям:

Иерархия начинается с корневой вершины.

Каждая вершина соответствует одному или нескольким атрибутам.

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

Каждая вершина, находящаяся на уровне i, соединена с одной и только одной вершиной уровня i-1, за исключением корневой вершины.

Корневая вершина может быть связана с одной или несколькими зависимыми вершинами.

Доступ к каждой вершине происходит через корневую по единственному пути

Существует произвольное количество вершин каждого уровня.

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

Операции в ИМД имеют нелогичный позаписный характер. Аппарат перемещения по структуре в графовых моделях служит для установки тех объектов данных, к которым будет применяться очередная операция манипулирования данными. Такие объекты называются текущими. Механизмы доступа к данным и перемещения по структуре данных в таких моделях достаточно сложны и существенным образом опираются на концепцию текущего состояния механизма доступа.[7, 10, 11, 12].

Основные достоинства ИМД: простота построения и использования, обеспечение определенного уровня независимости данных, простота оценки операционных характеристик. Основные недостатки: отношение "многие ко многим" реализуется очень сложно, дает громоздкую структуру и требует хранения избыточных данных, что особенно нежелательно на физическом уровне, иерархическая упорядоченность усложняет операции удаления и включения, доступ к любой вершине возможен только через корневую, что увеличивает время доступа. К числу СУБД иерархического типа можно отнести PC/Focus, Team-Up, DataEdge, также разработанную в нашей стране систему HИКА, преемницу широко распространенной советской системы ИHЕС для ЕС ЭВМ. Одной из наиболее важных сфер применения первых иерархических СУБД было планирование производства для компаний, занимающихся выпуском продукции. Например, если автомобильная компания хотела выпустить 10000 машин одной модели и 5000 машин другой модели, ей необходимо было знать, сколько деталей следует заказать у своих поставщиков. Чтобы ответить на этот вопрос, необходимо определить, из каких деталей состоят эти части и т.д. Например, машина состоит из двигателя, корпуса и ходовой части; двигатель состоит из клапанов, цилиндров, свеч и т.д. Работа со списками составных частей была как будто специально предназначена для компьютеров.

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

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



Ограничения целостности

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

В иерархических системах поддерживалась некоторая форма представлений БД на основе ограничения иерархии.

Сетевая модель данных

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

В СМД элементарные данные и отношения между ними представляются в виде ориентированной сети (вершины - данные, дуги - отношения).[7].



Если структура данных оказывалась сложнее, чем обычная иерархия, простота структуры иерархической базы данных становилась её недостатком. Например, в базе данных для хранения заказов один заказ мог участвовать в трёх различных отношениях предок/потомок, связывающих заказ с клиентом, разместившим его, со служащим, принявшим его, и с заказанным товаром, что иллюстрирует рисунок 2. Такие структуры данных не соответствовали строгой иерархии IMS.

В связи с этим для таких приложений, как обработка заказов, была разработана новая сетевая модель данных. Она являлась улучшенной иерархической моделью, в которой одна запись могла участвовать в нескольких отношениях предок/потомок. В сетевой модели такие отношения назывались множествами. В 1971 году на конференции по языкам систем данных был опубликован официальный стандарт сетевых баз данных, который известен как модель CODASYL. Компания IBM не стала разрабатывать собственную сетевую СУБД и вместо этого продолжала наращивать возможность IMS. Но в 70-х годах независимые производители программного обеспечения реализовали сетевую модель в таких продуктах, как IDMS компании Cullinet, Total компании Cincom и СУБД Adabas, которые приобрели большую популярность.

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

- Гибкость. Множественные отношения предок/потомок позволяли сетевой базе данных хранить данные, структура которых была сложнее простой иерархии.

- Стандартизация. Появление стандарта CODASYL популярность сетевой модели, а такие поставщики мини-компьютеров, как DigitalEquipmentCorporation и DataGeneral, реализовали сетевые СУБД.

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

Конечно, у сетевых баз данных были недостатки. Как и иерархические базы данных, сетевые базе данных были очень жесткими. Наборы отношений и структуру записей приходилось задавать наперёд. Изменение структуры базы данных обычно означало перестройку всей базы данных.

Как иерархическая, так и сетевая база данных были инструментами программистов. Чтобы получить ответ на вопрос типа "Какой товар наиболее часто заказывает компания AcmeManufacturing?", программисту приходилось писать программу для навигации по базе данных. Реализация пользовательских запросов часто затягивалась на недели и месяцы, и к моменту появления программы информация, которую она предоставляла, часто оказывалась бесполезной.[7, 10].

Ограничения целостности.

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

Реляционная модель данных

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

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

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

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

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

Поскольку в программной реализации дипломной работы избран реляционный подход, как наиболее подходящий, опишем его более подробно.[3, 7, 8, 12].

Таблицы

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

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

Структура таблицы включает следующую информацию:

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

Столбцы таблицы - Категории информации, сохраненной в таблице. Каждый столбец имеет имя и тип данного.

Табличные и столбцовые ограничения - Ограничения целостности, определенные на уровне таблицы или на уровне столбца.[3, 7, 8, 12].

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

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

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

Столбцы таблицы упорядочены слева направо, и их порядок определяется при создании таблицы. В любой таблице всегда есть как минимум один столбец. В стандарте ANSI/ISO не указывается максимально допустимое число столбцов в таблице, однако почти во всех коммерческих СУБД этот предел существует и обычно составляет примерно 255 столбцов.

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

В таблице может содержаться любое количество строк. Вполне допустимо существование таблицы с нулевым количеством строк. Такая таблица называется пустой. Пустая таблица сохраняет структуру, определённую её столбцами, просто в ней не содержатся данные. Стандарт ANSI/ISO не накладывает ограничений на количество строк в таблице, и во многих СУБД размер таблиц ограничен лишь свободным дисковым пространством компьютера. В других СУБД имеется максимальный предел, однако он весьма высок - около двух миллиардов строк, а иногда и больше.[12].

Ключевые поля

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

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

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

Если поле содержит уникальные значения, такие как коды или инвентарные номера, то это поле можно определить как простой ключ. Если выбранное поле содержит повторяющиеся или пустые значения, то оно не будет определено как ключевое. Для определения записей, содержащих повторяющиеся данные, можно выполнить запрос на поиск повторяющихся записей. Если устранить повторы путем изменения значений невозможно, то следует либо добавить в таблицу поле счетчика и сделать его ключевым, либо определить составной ключ.[3, 7, 8, 12].

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

Хотя первичные ключи являются важной частью реляционной модели данных, в первых реляционных СУБД (System/R, DB2, Oracle и других) не была обеспечена явным образом их поддержка. Как правило, проектировщики базы данных сами следили за тем, чтобы у всех таблиц были первичные ключи, однако в самих СУБД не было возможности определить для таблицы первичный ключ. И только в СУБД DB2 Version 2, появившейся в апреле 1988 года, компания IBM реализовала поддержку первичных ключей. После этого подобная поддержка была добавлена в стандарт ANSI/ISO.[3, 7, 8, 12].

Индексы.

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

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

Создать индексы, как и ключи, можно по одному или нескольким полям. Составные индексы позволяют при отборе данных группировать записи, в которых первые поля могут иметь одинаковые значения. Индексировать поля требуется для выполнения частых поисков, сортировок или объединений с полями из других таблиц в запросах. Ключевые поля таблицы индексируются автоматически. Нельзя индексировать поля с типом данных поле МЕМО, гиперссылка или объект OLE. Для остальных полей индексирование используется, если поле имеет текстовый, числовой, денежный тип или тип даты/времени и требуется осуществлять поиск и сортировку значений в поле. Если предполагается, что будет часто выполняться сортировка или поиск одновременно по двум и более полям, можно создать составной индекс. Например, если для одного и того же запроса часто устанавливается критерий для полей Имя и Фамилия, то для этих двух полей имеет смысл создать составной индекс. При сортировке таблицы по составному индексу сначала осуществляется сортировка по первому полю, определенному для данного индекса. Если в первом поле содержатся записи с повторяющимися значениями, то сортировка осуществляется по второму полю и т. д.[3, 7, 8, 12].

Отношения предок/потомок.

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

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

Внешние ключи

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

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

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

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

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

Реляционная алгебра.

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

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

- объединения таблиц;

- пересечения таблиц;

- взятия разности таблиц;

- прямого произведения таблиц.

Специальныереляционные операции включают:

- ограничение таблицы;

- проекцию таблицы;

- соединение таблиц;

- деление таблиц.

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

Ограничения целостности.

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

Нормализация базы данных.

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

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

Нормализация обычно подразделяется на пять форм или стадий-- от первой нормальной формы по пятую нормальную форму. То есть просто пять установок реляционного критерия, который либо обнаруживает таблицу, либо нет. Каждая последующая стадия строится на предыдущей. Формально существует пять форм, но на практике, как правило, используется только первые три. Последние две считаются слишком специальными, чтобы их применять к обычным проектам баз данных.[7, 8, 10].

Первая нормальная форма.

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

Поле считается неделимым, если оно содержит только один элемент данных. Например, поле Address, которое содержит не только название улицы, но также и города, почтовый код, не является неделимым. Чтобы соответствовать первой нормальной форме, такие столбцы должны быть разбиты на несколько полей.[7, 8, 10].

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

Вторая нормальная форма.

Для того чтобы привести таблицу ко второй нормальной форме, нужно, чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и от каждого поля в первичном ключе, если последний состоит из нескольких полей. Это значит, что каждое не ключевое поле должно уникально определяться первичным ключом и полями, его составляющими.[7, 8, 10].

Третья нормальная форма.

Для того чтобы таблица была приведена к третьей нормальной форме, нужно, чтобы все не ключевые поля полностью зависели от первичного ключа таблицы и не зависели друг от друга. Таким образом, к квалификации второй нормальной формы добавляется требование независимости каждого не ключевого поля таблицы от других не ключевых полей.[7, 8, 10].

Четвертая нормальная форма.

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

Конечно же, поскольку два столбца находятся во взаимоотношении многие-ко-многим, то они уже не являются независимыми, и тем самым уже нарушают третью нормальную форму. По этой причине четвертая нормальная форма рассматривается больше теоретически, т.к. частично она перекрывается третьей нормальной формой.[7, 8, 10].

Пятая нормальная форма.

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

На практике идея сохранения всех элементов в базе данных в процессе нормализации воплощается чисто интуитивно. Ведь вряд ли будут слепо выбрасывать из таблиц элементы данных. Но тем не менее, пятая нормальная форма призвана застраховать вас от такого несчастного случая.[7, 8, 10].

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

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

Среда программирования напоминает пакет VisualBasic. В вашем распоряжении несколько отдельных окон: меню и инструментальные панели, ObjectInspector (в котором можно видеть свойства объекта и связанные с ним события), окна визуального построителя интерфейсов (VisualUserInterfaceBuilder), ObjectBrowser (позволяющее изучать иерархию классов и просматривать списки их полей, методов и свойств), окна управления проектом (ProjectManager) и редактора.

Delphi содержит полноценный текстовый редактор типа Brief, назначения клавиш в котором соответствуют принятым в Windows стандартам, а глубина иерархии операций Undo неограниченна. Как это стало уже обязательным, реализовано цветовое выделение различных лексических элементов программы. Процесс построения приложения достаточно прост. Нужно выбрать форму (в понятие формы входят обычные, диалоговые, родительские и дочерние окна MDI), задать ее свойства и включить в нее необходимые компоненты (видимые и, если понадобится, неотображаемые): меню, инструментальные панели, строку состояния и т. п., задать их свойства и далее написать (с помощью редактора исходного кода) обработчики событий. ObjectBrowser Окна типа ObjectBrowser стали неотъемлемой частью систем программирования на объектно-ориентированных языках. Работа с ними становится возможной сразу после того, как вы скомпилировали приложение.

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

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

VisualComponentLibrary (VCL) Богатство палитры объектов для построения пользовательского интерфейса - один из ключевых факторов при выборе инструмента визуального программирования. При этом для пользователя имеет значение как число элементов, включенных непосредственно в среду, так и доступность элементов соответствующего формата на рынке. [4, 22].

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

Компиляторы языка Pascal компании Borland никогда не заставляли пользователя подолгу ждать результатов компиляции. Производители утверждают, что на сегодня данный компилятор - самый быстрый в мире. Компилятор, встроенный в Delphiпозволяет обрабатывать 120 тыс. строк исходного текста в минуту на машине 486/33 или 350 тыс. - при использовании процессора Pentium/90. Он предлагает легкость разработки и быстрое время проверки готового программного блока, характерного для языков четвертого поколения (4GL) и в то же время обеспечивает качество кода, характерного для компилятора 3GL. Кроме того, Delphi обеспечивает быструю разработку без необходимости писать вставки на Си или ручного написания кода (хотя это возможно).

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

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

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

Мощный объектно-ориентированный язык

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

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

- введено понятие класса.

- реализованы методы классов, аналогичные статическим методам C++. Они оперируют не экземпляром класса, а самим классом.

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

- введена обработка исключительных ситуаций. В Delphi это устроено в стиле С++. Исключения представлены в виде объектов, содержащих специфическую информацию о соответствующей ошибке (тип и место- нахождение ошибки). Разработчик может оставить обработку ошибки, существовавшую по умолчанию, или написать свой собственный обработчик. Обработка исключений реализована в виде exception-handlingblocks(также еще называется protectedblocks), которые устанавливаются ключевыми словами try и end. Существуют два типа таких блоков:try...except и try...finally.

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

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

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

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

Язык программирования Delphi базируется на BorlandObjectPascal

Кроме того, Delphi поддерживает такие низкоуровневые особенности, как подклассы элементов управления Windows, перекрытие цикла обработки сообщений Windows, использование встроенного ассемблера.[22].

Объектно-ориентированная модель программных компонент

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