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

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

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

 

Реляционные БД (поля, записи, таблицы)

 

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

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

 

Первичный ключ

 

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

 

Простые и составные  ключи

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

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

 

Вторичный ключ. Связи между  таблицами.

 

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

 

 

 

 

 

Методология IDEF1

      Метод IDEF1, разработанный Т.Рэмей (T.Ramey), также основан на подходе П.Чена и позволяет построить модель данных, эквивалентную реляционной модели в третьей нормальной форме. В настоящее время на основе совершенствования методологии IDEF1 создана ее новая версия – методология IDEF1X. IDEF1X разработана с учетом таких требований, как простота изучения и возможность автоматизации. IDEF1X-диаграммы используются рядом распространенных CASE-средств (в частности, Erwin, Design/IDEF).

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

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

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

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

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

      Связь изображается линией, проводимой между сущностью-родителем и сущностью-потомком с точкой на конце линии у сущности-потомка. Мощность связи обозначается как показано на рисунке (мощность по умолчанию – N).

 Мощность связи

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

 Идентифицирующая связь

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

Неидентифицирующая связь

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

Атрибуты и первичные  ключи

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

Примеры внешних ключей

 

 

 

Case-средства разработки  баз данных

 

      ER-модели широко используются в практике создания БД. Они применяются при ручном и автоматизированном проектировании с использованием CASE-средств, поддерживающих весь цикл разработки СБД или отдельные его стадии. К таким средствам относятся: ProKit*WORKBENCH, Design / IDEF, CASE Oracle (Designer / 2000), Power Designer (S-Designor), ERWin, SILVERRUN, ERStudio и другие. CASE-средства являются сравнительно новым направлением в информационных технологиях. Первая версия инструментария Oracle появилась в 1989 г.

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

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

 

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

 

      CASE-средства показывают модель с разной степенью детализации:

 

• только обозначения сущностей и связей между ними;
• сущности + ключи;
• сущности + ключи + внешние ключи;
• сущности + все атрибуты.

 

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

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

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

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

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

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

 

Erwin

 

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

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

AllFusion Erwin Data Modeler (Erwin) позволяет наглядно отображать сложные структуры данных. Удобная в использовании графическая среда AllFusion Erwin Data Modeler упрощает разработку базы данных и автоматизирует множество трудоёмких задач, уменьшая сроки создания высококачественных и высокопроизводительных транзакционных баз данных и хранилищ данных. Данное решение улучшает коммуникацию организации, обеспечивая совместную работу администраторов и разработчиков баз данных, многократное использование модели, а также наглядное представление комплексных активов данных в удобном для понимания и обслуживания формате.

 

IBExpert

 

      IBExpert — GUI-оболочка (Graphical user interface – разновидность пользовательского интерфейса, в котором элементы интерфейса (меню, кнопки, значки, списки и т. П.), представленные пользователю на дисплее, исполнены в виде графических изображений.), предназначенная для разработки и администрирования баз данных InterBase и Firebird, а также для выбора и изменения данных, хранящихся в базах.

 

      Как основные достоинства IBExpert разработчики указывают:

 

• поддержка InterBase версий 4.х, 5.х, 6.х, 7.х; Firebird 1.х, 2.x, 3.x; Yaffil 1.х;
• работа одновременно с несколькими базами данных;
• отдельные редакторы для всех объектов БД с синтаксической подсветкой;
• мощный SQL редактор с историей запросов и возможностью фонового выполнения запросов;
• автозавершение кода SQL (название таблиц, полей, и т.п.)
• отладчик хранимых процедур и триггеров;
• поиск в метаданных;
• полное и частичное извлечение данных и метаданных;
• анализатор зависимостей объектов баз данных;
• отчеты по метаданным;
• менеджеры пользователей и пользовательских привилегий;
• экспорт данных в различные форматы.

 

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

 

 

Технология  доставки пенсии и пособий населению (технологическая  схема и  описание технологии).

 

 

      УПРФ – управление пенсионным фондом России

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