Введение в объект управления данными data control


Содержание

Введение в SQL

Что такое SQL (Structured Query Language)?

SQL (Structured Query Language) — язык структурированных запросов.

SQL (Structured Query Language, язык структурированных запросов) — это специальный язык, используемый для определения данных, доступа к данным и их обработки. Язык SQL относится к непроцедурным (nonprocedural) языкам — он лишь описывает нужные компоненты (например, таблицы) и желаемые результаты, не указывая, как именно эти результаты должны быть получены. Каждая реализация SQL является надстройкой над процессором базы данных (database engine), который интерпретирует операторы SQL и определяет порядок обращения к структурам БД для корректного и эффективного формирования желаемого результата.

Стандарт SQL определяется ANSI — American National Standarts Institute (Американским Национальным Институтом Стандартов) и в настоящее время принят ISO — International Standarts Organization (Международной Организацией по Стандартизации).

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

Что можно делать с помощью SQL?

  • SQL позволяет создавать таблицы данных.
  • SQL позволяет хранить данные.
  • SQL позволяет получать данные.
  • SQL позволяет изменять данные.
  • SQL позволяет изменять структуру таблиц.
  • SQL позволяет объединять данные.
  • SQL позволяет выполнять вычисления.
  • SQL позволяет обеспечивать защиту данных.

Команды SQL

Команды SQL разделяются на следующие группы:

  • Команды языка определения данных — DDL (Data Definition Language). Эти SQL команды можно использовать для создания, изменения и удаления различных объектов базы данных.
  • Команды языка управления данными — DCL (Data Control Language). С помощью этих SQL команд можно управлять доступом пользователей к базе данных и использовать конкретные данные (таблицы, представления и т.д.).
  • Команды языка управления транзакциями — TCL (Тгаnsасtiоn Соntrol Language). Эти SQL команды позволяют определить исход транзакции.
  • Команды языка манипулирования данными — DML (Data Manipulation Language). Эти SQL команды позволяют пользователю перемещать данные в базу данных и из нее.

Основные ключевые слова, используемые в статье«Введение в SQL»:

Управление данными
Data management

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

Содержание

Управление данными (англ. data management) — процесс, связанный с накоплением, организацией, запоминанием, обновлением, хранением данных и поиском информации.

К управлению данными относятся

  • Анализ данных
  • Моделирование данных
  • Управление базами данных
  • Работа с хранилищами данных
  • Извлечение, преобразование и загрузка данных
  • Добыча данных
  • Обеспечение качества данных
  • Защита данных
  • Шифрование данных
  • Управление метаданными (репозиториями данных)
  • Архитектура данных

2020: Эффективное управление данными увеличивает продажи в 3 раза

Согласно исследованиям Experian, в которых приняли участие 1400 организаций из восьми стран мира, компании все больше осознают экономический потенциал информации: по мнению 79% опрошенных, к концу десятилетия данные о клиенте будут определять большую часть решений о продаже. Однако при этом почти все опрошенные — 90% — по-прежнему считают, что им недостает конструктивного подхода к эффективному управлению данными.

В среднем, почти 25% данных по клиентам содержать неточности. Среди наиболее распространенных ошибок:

  • неполные или отсутствующие данные
  • устаревшие сведения
  • дупликация данных
  • противоречивая информация

Согласно исследованию Experian, компании полагают, что могли бы увеличить продажи почти на 29% при наличии точных клиентских данных.

Согласно оценкам, в 2012 г. каждый день создавался впечатляющий объем данных –2,5 квинтильона байтов – и это в то время, когда мобильная связь, согласно оценкам, охватила 61% населения земного шара. Если исходить из того, что к 2020 г. эта цифра возрастет до 70%, становится очевидно, что объем данных в ближайшие годы будет расти экспоненциально.

Такой «взрывной» рост данных является вызовом для компаний. Как отметили 84% респондентов, их организация в настоящее время считает данные неотъемлемым компонентом бизнес-стратегии. В связи с этим 82% компаний в ближайшие пять лет планируют принять на работу специалистов по данным. Как установило предыдущее исследование Experian, сегодня растет значимость директора по данным (CDO), который развивает работу с данными в рамках стратегической деятельности компании, обеспечивая улучшение финансовых результатов.

Управление данными также усложняется из-за растущих объемов информации и изменений в использовании каналов связи. По словам 39% респондентов (против 10% в прошлом году), их организация имеет 50 или более баз контактов. Кроме того, использование социальных сетей за последние 12 месяцев выросло на 81%.

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

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

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

2013: Специфика финансовых организаций

В декабре 2013 года Qlik (QlikTech) обнародовала результаты исследования, которое показало: несмотря на то, что после мирового финансового кризиса управление данными приобрело особое значение, более чем две трети (63%) руководителей финансовых компаний не считают необходимым рассматривать этот вопрос на уровне высшего руководства.

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

Помимо беспрецедентного увеличения объема ежедневно обрабатываемых данных, в действие введено множество нормативно-правовых актов, связанных с управлением данными – таких как закон Сарбейнза-Оксли, Правило 17а-4 Комиссии по ценным бумагам США, стандарты Базель III и Solvency II, а также принципы Базельского комитета по банковскому надзору BCBS 239 (агрегирование данных о рисках). В ответ на это финансовые учреждения должны были сформировать общие подходы в вопросах архитектуры и моделирования данных; решение этой задачи и обеспечивает управление данными.

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

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

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

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

Diplom Consult.ru

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

Пример некоторых DDL-команд:

Создать новую таблицу

Удалить существующую таблицу

Изменить структуру существующей таблицы

Команды манипулирования данными (Data Manipulation Language – dml)

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

Извлечь данные из таблицы

Добавить новую строку данных в таблицу

Удалить строки из таблицы

Изменить информацию в строках таблицы

Команды управления транзакциями (Transaction Control Language — tcl)

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

Завершить транзакцию и зафиксировать все изменения в БД

Отменить транзакцию и отменить все изменения в БД

Установить некоторые условия выполнения транзакции

Команды управления доступом (Data Control Language – dcl)

DCL-команды управляют доступом пользователей к БД и отдельным объектам:

Работа с командами sql Извлечение данных, команда select

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

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

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

SELECT TabNum FROM Employees

SELECT TabNum, Name FROM Employees

Звездочка (*) на месте списка столбцов обозначает все столбцы таблицы:

SELECT * FROM Employees

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

SELECT Employees.Name, Departments.Name FROM …

Компоненты Data Access


Компоненты вкладки Data Access (рис. 18.11) служат для создания в приложении элементов управления доступом к базам данных.

Рис. 11. Компоненты вкладки Data Access

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

Компоненты Data Controls

Компоненты вкладки Data Controls (рис. 18.12) создают специальные элементы управления базами данных, доступные пользователю из приложения.

Рис. 12. Компоненты вкладки Data Controls

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

Компоненты Internet Express

Компоненты вкладки Internet Express (рис. 18.13) позволяют осуществить построение приложений с архитектурой «клиент — сервер», которые действуют по протоколам TCP-IP и HTTP. Кроме того, они позволяют создать распределенное сетевое приложение, Web-сервер которого будет выступать в роли клиентского приложения MIDAS. MIDAS (Multi-tier Distributed Application Services, многоуровневый сервис распределенных приложений) — это технология, разработанная компанией Inprise/Borland для создания и эксплуатации надежных, высокопроизводительных, распределенных систем на основе многозвенной архитектуры.

Рис. 13. Компоненты вкладки Internet Express

XML Broker (XML-брокер) — представляет пакеты данных от поставщика сервисного приложения с кодировкой HML.

? InetXPage Producer (Производитель интернет-страниц) — позволяет сгенерировать страницу HTML с информацией, полученной от сервисного приложения MIDAS.

Введение в объект управления данными data control

НАЦИОНАЛЬНЫЙ СТАНДАРТ РОССИЙСКОЙ ФЕДЕРАЦИИ

ЭТАЛОННАЯ МОДЕЛЬ УПРАВЛЕНИЯ ДАННЫМИ

Reference model of data management

Дата введения 2008-09-01

Цели и принципы стандартизации в Российской Федерации установлены Федеральным законом от 27 декабря 2002 г. N 184-ФЗ «О техническом регулировании», а правила применения национальных стандартов Российской Федерации — ГОСТ Р 1.0-2004 «Стандартизации в Российской Федерации. Основные положения»

Сведения о стандарте

1 ПОДГОТОВЛЕН Открытым акционерным обществом «Научно-исследовательский центр контроля и диагностики технических систем» (ОАО «НИЦ КД») на основе собственного аутентичного перевода стандарта, указанного в пункте 4

2 ВНЕСЕН Техническим комитетом по стандартизации ТК10 «Перспективные производственные технологии, менеджмент и оценка риска»

3 УТВЕРЖДЕН И ВВЕДЕН В ДЕЙСТВИЕ Приказом Федерального агентства по техническому регулированию и метрологии от 27 декабря 2007 г. N 573-ст

4 Настоящий стандарт идентичен международному стандарту ИСО/МЭК ТО 10032:2003 «Информационная технология. Эталонная модель управления данными» (ISO/IEC TR 10032:2003 «Information technology — Reference model of data management»).

Наименование настоящего стандарта изменено относительно наименования указанного международного стандарта для приведения в соответствие с ГОСТ Р 1.5-2004 (подраздел 3.5)

5 ВВЕДЕН ВПЕРВЫЕ

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

Введение

Существует множество способов реализации систем управления данными* для определения эталонной модели управления данными. Для определения функций управления данными или ссылок на них используют различные термины, для описания различных функций применяют одинаковые термины. Поэтому необходима стандартизация функций управления данными. Настоящий стандарт представляет эталонную модель управления данными и определяет области стандартизации этой модели.
________________
* Данные — это информация, представленная в формализованном виде, пригодном для ее передачи, интерпретации и обработки с участием человека или автоматическими средствами ( ГОСТ 34.320-96 ). Как правило, данные структурируют в виде таблицы.

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

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

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

a) для идентификации интерфейсов;

b) для позиционирования всех таких интерфейсов относительно друг друга;

c) для идентификации средств обеспечения каждого интерфейса;

d) для идентификации процесса поддержки каждого интерфейса и, где это применимо, данных, необходимых для такой поддержки;

e) для распределения использования интерфейсов в соответствии со стадиями жизненного цикла информационных систем;

f) для идентификации связанных альтернатив, ассоциированных с соответствующим идентифицированным интерфейсом.

В настоящем стандарте выделены три главные цели стандартизации управления данными:

a) совместимость ресурсов;

b) минимизация стоимости поддержки информационной системы на всех этапах ее жизненного цикла;

c) оптимальное использование достижений стандартизации и оптимизация организации работ в этой области.

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

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

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

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

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

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

Описание эталонной модели управления данными представлено в настоящем стандарте следующим образом:

— раздел 4 содержит общие положения управления данными и требования, основанные на особенностях информационных систем;

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

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

— в разделе 7 описаны цели и принципы стандартизации управления данными;

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

— в приложении В показана связь действующих стандартов и проектов стандартов с архитектурной моделью.

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

Пояснения некоторых положений настоящего стандарта приведены в виде сносок, выделенных курсивом.

1 Область применения

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

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

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

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

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

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

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

2 Термины и определения

В настоящем стандарте использованы следующие термины с соответствующими определениями.

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

2.1 управление доступом (access control): Процесс, заключающийся в предупреждении несанкционированного использования ресурсов.

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

2.2 данные управления доступом (access control data): Данные, связанные с определением или модификацией привилегий управления доступом.

2.3 механизм управления доступом (access control mechanism): Механизм, предназначенный для реализации политики обеспечения и повышения безопасности.

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

2.5 прикладной процесс (application process): Процесс, определенный в соответствии с требованиями конкретной информационной системы.

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

2.7 контрольный журнал (audit trail): Журнал, предназначенный для регистрации процессов функционирования в информационной системе.

2.8 санкционирование (authorization): Определение привилегий для конкретного идентифицированного пользователя.

2.9 связывание (binding): Установление отношений между конкретными определениями данных и процессами.

2.10 клиент (client): Субъект (пользователь или процесс), запрашивающий услуги, предоставляемые на другом процессоре (т.е. сервере).

2.11 отношение клиент-сервер (client-server relationship): Связь, устанавливаемая в момент, когда клиент запрашивает услугу, которая должна быть выполнена сервером.

2.12 коммуникационное соединение (communications linkage): Средства обмена данными между компьютерными системами или между пользователем и компьютерными системами.

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

2.14 конфигурация (configuration): Совокупность процессов информационной системы и способ взаимосвязи этих процессов.

2.15 управление конфигурацией (configuration management): Деятельность, связанная с управлением конфигурацией информационной системы на всех этапах жизненного цикла.

2.16 правило ограничения целостности (constraining rule): Правило, являющееся частью средства моделирования данных и управляющее выполнением требований, обеспечивающих целостность определенного набора данных.

2.17 ограничения (constraint): Ограничения на значения определенного набора данных.

2.18 стандарт содержания данных (data content standard): Логические требования к данным, имеющим общую область применения и используемым во многих прикладных системах.

2.19 определение данных (data definition): Описание правил, которым должен удовлетворять один или более набор данных.

2.20 экспорт данных (data export): Услуга по управлению данными, заключающаяся в извлечении данных из базы данных и создании копии этих данных, организованных в соответствии с форматом обмена данными.

2.21 импорт данных (data import): Услуга по управлению данными, заключающаяся во вставке данных в базу данных, организованную в соответствии с форматом обмена данными.

2.22 независимость данных (data independence): Независимость процессов от объектов данных, состоящая в том, что объекты данных могут быть изменены без нарушения процессов.

2.23 целостность данных (data integrity): Соответствие значений всех данных базы данных определенному непротиворечивому набору правил.

2.24 формат обмена данными (data interchange format): Правила структурирования определенных данных, устанавливающие формат данных, необходимый для экспорта данных из одной системы управления данными и их импорта в другую систему управления данными.

2.25 стандарт обмена данными (data interchange standard): Стандарт, определяющий совокупность данных в соответствии с правилами их структурирования, обеспечивающими обмен данными между двумя компьютерными системами.

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

2.27 среда управления данными (data management environment): Используемые в компьютерной системе формализованные принципы описания данных и соответствующие элементы их обработки.

2.28 услуга по управлению данными (data management service): Услуга, предоставляемая системой управления данными.

2.29 сеанс управления данными (data management session): Период времени, в течение которого клиент пользуется услугами процесса управления данными.

2.30 система управления данными (data management system): Система, предназначенная для организации данных и управления ими.

2.31 процесс манипулирования данными (data manipulation process): Процесс, семантика которого установлена правилами манипулирования данными в системе моделирования данных.

2.32 правило манипулирования данными (data manipulation rule): Правило, которому необходимо следовать при создании процесса или которому автоматически следует система управления данными при выполнении процесса.

2.33 средство моделирования данных (data modeling facility): Совокупность правил, предназначенных для определения схемы данных и манипулирования данными, хранимыми в соответствии со схемой.

2.34 правило структурирования данных (data structuring rule): Правило, определяющее способ структурирования набора данных.

2.35 тип данных (data type): Поименованная совокупность данных с общими статическими и динамическими свойствами, устанавливаемыми формализованными требованиями к данным рассматриваемого типа.

2.36 база данных (database): Совокупность данных, хранимых в соответствии со схемой данных, манипулирование которыми выполняют в соответствии с правилами средств моделирования данных.

2.37 контроллер базы данных (database controller): Абстрактное представление для набора услуг, согласованных с конкретным средством моделирования данных.

2.38 среда базы данных (database environment): Совокупность базы данных, связанной с ней схемы и контроллера базы данных.

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

2.40 управление базой данных (database management): Процесс создания, использования и поддержки базы данных.

2.41 система управления базами данных; СУБД (database management system; DBMS): Совокупность программных и лингвистических средств общего или специального назначения, обеспечивающих управление созданием и использованием баз данных.


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

2.43 распределенная система базы данных (distributed database): Совокупность данных, распределенных между двумя или более базами данных.

2.44 распределенная информационная система (distributed information system): Информационная система, объекты данных и/или процессы которой распределены на две или более базы данных.

2.45 данные распределения (distribution data): Сведения, определяющие информацию о размещении, дублировании и фрагментации объектов в распределенной системе базы данных.

2.46 фрагментация (fragmentation): Распределение данных между двумя или более средами управления базами данных.

2.47 функциональный стандарт (functional standard): Стандарт, состоящий из набора согласованных между собой стандартов.

2.48 горизонтальная фрагментация * (horizontal fragmentation): Фрагментация, при которой распределение данных сформировано из данных всех возможных типов одной записи.
________________
* Если данные представлены в виде таблицы, то горизонтальная фрагментация — это набор данных, сформированный из строк таблицы.

2.49 информационная система (information system): Система, организующая обработку информации о предметной области и ее хранение.

2.50 средства моделирования обмена данными (interchange data modelling facility): Средства моделирования данных, поддерживающие обмен данными между системами управления данными.

2.51 стандарт интерфейса (interface standard): Стандарт, определяющий услуги, доступные в интерфейсе, для процессов.

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

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

2.54 постоянные данные (persistent data): Данные, сохраняющиеся в информационной системе в течение более одного сеанса управления данными.

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

2.56 процесс (process): Компонент информационной системы, реализующий конкретный алгоритм обработки данных.

2.57 процесс соединения (processing linkage): Предоставление возможного взаимодействия между процессорами.

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

2.59 схема (schema): Описание содержания, структуры и ограничений, используемых для создания и поддержки базы данных.

2.60 сервер (server): Процессор, предоставляющий услуги одному или более другому процессору.

2.61 услуга (service): Предоставление функциональных возможностей одним процессором другим процессорам или одним процессом другим процессам.

2.62 интерфейс услуг (services interface): Определенный набор услуг, обеспечиваемых процессом или процессором.

2.63 сеанс (session): Промежуток времени, в течение которого клиент может активно взаимодействовать с сервером или клиент и сервер получают данные друг о друге.

2.64 исходная схема (source schema): Определение данных или набор определений данных до их преобразования в схему.

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

2.66 транзитные данные (transient data): Данные, поступающие в информационную систему или исключаемые из нее, а в случае распределенной системы — данные, перемещаемые из одной компьютерной системы в другую при выполнении одной или более транзакции.

2.67 процессор пользователя (user processor): Процессор, предоставляющий услуги пользователю и являющийся клиентом (прямым или косвенным) контроллера базы данных.

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

2.69 версия (version): Конфигурация всей информационной системы или ее части в конкретный момент времени.

2.70 вертикальная фрагментация * (vertical fragmentation): Фрагментация, при которой распределение данных сформировано из значений данных одного и того же типа.
________________
* Если данные представлены в виде таблицы, то вертикальная фрагментация — это набор данных, сформированный из столбцов таблицы.

3 Обозначения и сокращения

3.1 В настоящем стандарте применены следующие обозначения (изображения) и сокращения.

3.1.1 Постоянные данные

3.1.2 Коммуникационное соединение (каналы обмена информацией)

3.1.3 Технологическое соединение (связь между процессами обработки данных)

3.1.4 Класс процесса

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

3.1.5 Класс процессора

3.1.6 Класс процессора с интерфейсом услуг

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

3.1.7 Имена классов

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

3.2 Сокращения

ACID* — атомарность, непротиворечивость, изолированность, долговечность;
________________
* ACID — Atomicity, Consistency, Isolation and Durability properties.

DBMS — система управления базами данных (см. 2.41);

IRDS* — системы словаря информационных ресурсов;
________________
* IRDS — Information Resource Dictionary System.

NDL* — язык базы данных сети;
________________
* NDL — Network Database Language.

OSI* — открытая взаимосвязь систем;
________________
* OSI — Open Systems Interconnection.

RDA* — удаленный доступ базы данных;
________________
* RDA — Remote Database Access.

SQL* — язык структурированных запросов.
________________
* SQL — Structured Query Language.

4 Требования к управлению данными

4.1 Цель

Целью раздела является описание:

a) основных понятий, связанных с информационными системами;

b) положений системы управления данными в информационной системе;

c) области применения управления данными.

4.2 Информационные системы

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

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

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

Управление данными в настоящем стандарте касается организации постоянных данных и управления ими. Система, выполняющая функцию организации постоянных данных и управления ими, называется системой управления данными.

4.2.1 Положение системы управления данными в информационной системе

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

Рисунок 1 — Положение системы управления данными в информационной системе

Рисунок 1 — Положение системы управления данными в информационной системе

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

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

На рисунке 1 показано следующее:

a) система управления данными предоставляет услуги, управляющие набором постоянных данных;

b) взаимодействие с пользователем обеспечивает интерфейс человек-компьютер;

c) прикладной процесс предоставляет возможности, необходимые для выполнения требований конкретной информационной системы;

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

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

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

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

h) комбинация системы управления данными и постоянных данных представляет собой среду базы данных.

4.3 База данных и схема

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

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

4.4 Средства моделирования данных

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

Правила структурирования данных и правила манипулирования данными — это средства моделирования данных.

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

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

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

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

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

4.5 Независимость данных

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

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

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

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

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

4.6 Услуги управления данными

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

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

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

4.7 Процессоры и интерфейсы

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

Илон Маск рекомендует:  Strerror получить информацию об ошибке

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

4.8 Управление доступом

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

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

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

— определение и последующую модификацию управления доступом;

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

4.8.1 Определение и модификация привилегий управления доступом

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

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

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

4.8.2 Введение в действие управления доступом

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

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

4.8.3 Внешняя безопасность управления данными

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

a) аутентификация идентификации пользователя;

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

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

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

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

4.9 Требования к сопровождению управления данными

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

a) поддержание жизненного цикла информационных систем;

b) управление конфигурацией, управление версиями и вариантами;

c) параллельная обработка;

d) управление транзакциями базы данных;

e) поддержание и повышение производительности;


f) обращение к данным;

g) расширение средств моделирования данных;

h) поддержание различных средств моделирования данных в интерфейсе пользователя;

i) контрольные журналы;

k) логическое реструктурирование данных;

l) реорганизация физической памяти.

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

4.9.1 Поддержание жизненного цикла информационных систем

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

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

4.9.2 Управление конфигурацией, управление версиями и вариантами

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

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

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

4.9.3 Параллельная обработка

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

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

4.9.4 Управление транзакциями базы данных

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

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

b) непротиворечивость. После завершения работы транзакция базы данных оставляет базу данных в непротиворечивом состоянии;

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

d) долговечность. Сохранность изменений, совершенных транзакцией, независимо от сбоев и отказов системы.

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

4.9.5 Поддержание и повышение производительности

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

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

4.9.6 Обращение к данным

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

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

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

4.9.7 Расширение средств моделирования данных

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

4.9.8 Поддержание различных средств моделирования данных в интерфейсе пользователя

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

4.9.9 Контрольные журналы

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

4.9.10 Восстановление распределенной базы данных

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

4.9.11 Логическое реструктурирование данных

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

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

4.9.12 Реорганизация физической памяти

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

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

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

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

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

Эксплуатационные требования, связанные с распределяемыми данными, следующие:

a) управление распределением;

b) управление транзакцией базы данных;

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

f) автономность системы;

g) восстановление распределенной базы данных.

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

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

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

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

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

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

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

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

4.10.1 Управление распределением данных

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

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

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

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

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

a) без фрагментации;

b) с использованием горизонтальной фрагментации;

c) с использованием вертикальной фрагментации;

d) с использованием комбинации горизонтальной и вертикальной фрагментации.

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

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

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

4.10.2 Управление транзакцией базы данных

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

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

4.10.3 Связь

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

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

Необходимо иметь средства, предотвращающие потерю целостности баз данных из-за сбоя связи следующих видов:

— сообщение потеряно во время передачи;

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

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

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

4.10.4 Экспорт/импорт

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

4.10.5 Независимость распределения

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

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

4.10.6 Автономность системы

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

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

4.10.7 Восстановление распределенной базы данных

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

4.11 Системы словарей

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

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

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

5 Уровни данных и соответствующие процессы

5.1 Цель

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

5.2 Пара уровней

Конструкция «пара уровней» является способом описания связей между базой данных и схемой. Графическое представление (рисунок 2) применяют для иллюстрации связи базы данных с ее описанием.

Рисунок 2 — Структура «пары уровней»

Рисунок 2 — Структура «пары уровней»

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

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

5.2.1 Объединение в блоки пар уровней

Конкретная схема не только определяет данные, но и сама является набором сложных объектов данных, которые должны быть созданы и защищены и могут быть модифицированы. Средства управления данными пригодны для управления схемами. Схема в паре уровней может быть представлена в базе данных более высокого уровня, структура данных которой может быть определена схемой более высокого уровня. Эта база данных и схема составляют другую, более высокую пару уровней. Две пары уровней могут быть «объединенными в блоки», как показано на рисунке 3.

Рисунок 3 — Объединенные в блоки пары уровней

Рисунок 3 — Объединенные в блоки пары уровней

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

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

5.2.2 Рекурсивное использование пар уровней

Для потенциально сложных пар уровней требуется механизм ссылки на каждый уровень. Общие ярлыки (N), (N+1) и т.д. использованы в настоящем стандарте для отражения более высоких уровней при рассмотрении общих свойств.

Блокирование пар уровней происходит с помощью связывания схемы пары уровней (N) с базой данных следующей пары уровней (N+1). Первая пара уровней называется схемой (N), вторая — базой данных (N+1).

Обобщенное блокирование пар уровней с использованием обозначений приведено на рисунке 4.

Рисунок 4 — Обобщенное блокирование пар уровней

Рисунок 4 — Обобщенное блокирование пар уровней

5.2.3 Операции с использованием пар уровней

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

Рисунок 4 иллюстрирует указанные выше процессы следующим образом:

a) база данных (N) представляет данные, фактически предназначенные для манипулирования на уровне (N);

b) схема (N) представляет схему, способную управлять процессами, соответствующими паре уровней (N). Эта схема содержит определения данных только для базы данных (N);

c) база данных (N+1) содержит определения данных, которые были созданы в процессе проектирования базы данных (N) и поддерживались при функционировании системы. База данных (N+1) может также содержать другие данные, такие, например, как описания этих определений и проекты этих данных, и требования к процессам, которые их используют;

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

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

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

5.3 Зависимость пар уровней от средства моделирования данных

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

5.3.1 Пары уровней и правила структурирования данных

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

Представленная на рисунке 4 схема (N+1) ограничивает данные, которые могут быть созданы в базе данных (N+1). В результате этого схема (N+1) влияет на каждую исходную схему (N), содержащуюся в базе данных (N+1).

5.3.2 Пары уровней и правила манипулирования данными

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

5.4 Пары уровней и соответствующие процессы

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

Рисунки 5 и 6 иллюстрируют, как правила структурирования данных, используемые для определения схемы (N+1), влияют на процессы манипулирования данными в базе данных (N).

Рисунок 5 — Создание пустой базы данных

Рисунок 5 — Создание пустой базы данных

Рисунок 6 — Связывание данных и манипулирование данными

Рисунок 6 — Связывание данных и манипулирование данными

Использованы следующие пять процессов манипулирования данными: 1 — выбирать; 2 — активировать; 3 — связывать с правилами манипулирования данными; 4 — связывать с правилами структурирования данных; 5 — выбирать или модифицировать.

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

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

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

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

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

Шаг 3. Правила манипулирования данными, которые управляют выполнением процесса манипулирования данными (N), имеющего доступ к базе данных (N), являются теми же самыми или основанными на правилах, соответствующих схеме (N+1).

Шаг 4. Процесс манипулирования данными (N) для обеспечения его доступа к базе данных (N) должен соответствовать правилам средств моделирования данных в схеме (N+1). Если уровень (N+1) самый высокий, то это соответствие неявно.

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

Шаги 1 и 2 обеспечивают создание пустой базы данных. Шаг 3 устанавливает связь между средством моделирования данных, определенным на уровне (N+1), и процессом манипулирования данными (N). Этот шаг устанавливает сблокированность пар уровней. Оба элемента пары уровней необходимы для обеспечения корректного выполнения процессов управления данными.

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

5.5 Управление доступом для пар уровней

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

5.6 Модификация схемы

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

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

6 Архитектурная модель

6.1 Цель

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

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

6.2 Понятия моделирования

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

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

6.2.1 Характеристики процессоров эталонной модели

a) Архитектурную модель представляют в терминах процессоров, которые взаимодействуют как клиент и/или сервер. Эти термины используют для ссылок на процессоры, которые функционируют при конкретном взаимодействии. Специальный процессор может играть различные роли при других взаимодействиях.


b) При взаимодействии в формате «клиент-сервер» клиент делает запрос на услугу, включая любые значения данных, требуемые для этой услуги. Сервер обеспечивает один из следующих ответов:

1) признак (индикатор), что запрашиваемая услуга завершена;

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

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

4) сообщение, что запрашиваемые данные недоступны;

5) сообщение, что запрос сформулирован некорректно.

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

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

e) Процессор может быть клиентом нескольких серверов в любое время. Несколько серверов могут одновременно обслуживать нескольких клиентов.

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

6.2.2 Уровни абстракции

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

Для более детального описания архитектурной модели необходимо использовать:

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

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

6.2.3 Примечание для процессоров

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

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

Рисунок 7 — Пример диаграммы процессора

Рисунок 7 — Пример диаграммы процессора

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

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

6.3 Общая модель управления данными

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

Рисунок 8 — Общая модель управления данными

Рисунок 8 — Общая модель управления данными

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

6.3.1 Контроллер общей базы данных

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

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

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

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

Типичные услуги, обеспеченные контроллером базы данных:

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

b) дополнение и изменение определения данных в схеме базы данных;

c) извлечение определений данных из схемы базы данных;

d) дополнение, изменение данных в базе данных или их удаление;

e) извлечение данных из базы данных;

f) начало транзакции базы данных после получения одного или более запроса на услуги;

g) завершение транзакции с сохранением или отменой изменений, внесенных транзакцией;

h) установление процедур резервного копирования для базы данных;

i) инициация процедур восстановления для базы данных;

j) реорганизация базы данных;

k) прекращение сеанса.

Запросы на эти услуги выражают контроллеру базы данных в виде:

a) операторов на языке базы данных;

b) сообщений, поступающих на интерфейс услуг управления данными;

c) вызовов процедур.

6.3.2 Процессор пользователя

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

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

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

6.3.3 Пользователь

Пользователь — имя класса лиц или процессоров, которые заказывают услуги, предоставляемые процессором пользователя.

6.4 Требования к модели в различных средах

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

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

6.5 Среда базы данных

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

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

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

Илон Маск рекомендует:  Что такое код getkeynametext

Рисунок 9 — Пример доступа к среде базы данных

Рисунок 9 — Пример доступа к среде базы данных

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

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

Рисунок 10 — Пример доступа ко многим средам базы данных

Рисунок 10 — Пример доступа ко многим средам базы данных

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

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

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

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

6.6 Управление распределенными данными

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

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

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

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

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

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

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

Рисунок 11 — Управление распределенными данными

Рисунок 11 — Управление распределенными данными

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

6.6.1 Контроллер распределения

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

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

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

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

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

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

6.6.2 Роль контроллера распределения и пар уровней

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

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

6.7 Модель экспорта/импорта

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

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

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

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

Рисунок 12 — Модель экспорта/импорта

Рисунок 12 — Модель экспорта/импорта

6.8 Управление доступом для управления данными

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

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

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

a) процессор управления доступом используется управляющим процессором в качестве сервера;

b) процессор управления доступом требует услуг, предоставляемых управляющим процессором;

c) процессор управления доступом может быть встроен в управляющий процессор.

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

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

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

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

Рисунок 13 — Управление доступом в распределенной среде

Рисунок 13 — Управление доступом в распределенной среде

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

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

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

7 Цели и принципы стандартизации управления данными

7.1 Цель

Настоящий раздел идентифицирует цели и принципы стандартизации управления данными.

Рассмотрены три составляющие стандартизации:

— технические цели, основанные на концепциях, приведенных в настоящем стандарте;

— средства достижения этих технических целей;

— разработка стандартов в области управления данными.

7.2 Технические цели стандартизации управления данными

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

a) поддержание сценариев распределения данных;

b) независимость размещения;

c) стандартизация управления транзакциями баз данных;

d) экспорт и импорт баз данных;

e) уменьшение сложности обработки данных;

f) обеспечение общей производительности в распределенных сценариях;

g) независимость данных;

h) мобильность приложений;

i) экстенсивное использование средств моделирования данных;

j) гибкое предоставление данных пользователю.

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

7.2.1 Поддержание сценариев распределения данных

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

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

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

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

7.2.2 Независимость размещения

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

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

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

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

7.2.3 Стандартизация управления транзакциями баз данных

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

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


7.2.4 Экспорт и импорт баз данных

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

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

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

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

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

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

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

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

7.2.5 Уменьшение сложности обработки данных

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

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

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

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

7.2.6 Общая производительность в распределенных сценариях

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

7.2.7 Независимость данных

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

7.2.8 Обеспечение мобильности приложений

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

7.2.9 Экстенсивное использование средств моделирования данных

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

7.2.10 Обеспечение гибкого представления данных пользователю

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

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

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

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

7.3 Средства достижения целей

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

a) общих средств моделирования данных для каждой пары уровней;

b) общего механизма обмена для всех пар уровней;

c) одинаковых процессоров, удобных для всех пар уровней;

d) стандартизованных услуг в интерфейсе контроллера базы данных;

e) стандартизованного подхода к управлению доступом;

f) стандартизованного представления данных, необходимых для средств взаимодействия;

g) обеспечения работы с фрагментацией данных;

h) разделения логических и физических структур;

i) доступа к схеме во время выполнения.

7.3.1 Общие средства моделирования данных для каждой пары уровней

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

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

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

7.3.2 Общий механизм обмена для всех пар уровней

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

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

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

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

7.3.3 Использование одних и тех же процессоров для всех пар уровней

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

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

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

7.3.4 Стандартизованные услуги в интерфейсе контроллера базы данных

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

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

7.3.5 Стандартизованный подход к управлению доступом

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

7.3.6 Стандартизованное представление данных, необходимых для средств взаимодействия

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

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

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

7.3.7 Обеспечение работы с фрагментацией данных

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

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

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

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

7.3.8 Разделение логических и физических структур

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

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

7.3.9 Доступ к схеме

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

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

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

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

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

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

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

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

7.3.10 Средства моделирования данных пользователя, отличные от средств моделирования обмена данных

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

7.4 Аспекты стандартизации управления данными

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

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

7.4.1 Категории стандартов управления данными

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

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

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

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

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

7.4.2 Роль средств моделирования данных в стандартизации

Понятие средства моделирования данных является фундаментальным в концепции стандартов управления данными. Существуют три пути использования средств моделирования данных в стандартах управления данными:

a) средства моделирования данных могут быть предметом отдельного стандарта;

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

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

7.4.3 Стили стандартизации

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

Идентифицированы следующие стили:

a) абстрактный синтаксис;

b) панели (абстрактный формат экрана);

c) конкретный синтаксис;

d) вызов процедуры;

e) условные обозначения (например, используемые в услугах OSI).

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

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

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

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

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

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

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

Приложение А (справочное). Взаимосвязанные международные стандарты

Одновременно с подготовкой настоящего стандарта в рамках ИСО/МЭК ТК1/ПК32 завершена или проводится разработка стандартов управления данными в различных областях, включенных в следующий список взаимосвязанных стандартов:

ИСО/МЭК 9075 (все части) Информационная технология. Языки базы данных. Язык структурированных запросов (SQL) (см. [1]-[9]);

ИСО/МЭК 9579:2000 Информационные технологии. Дистанционный доступ к базе данных для языка структурированных запросов (SQL) с расширением безопасности (см. [10]);

ИСО/МЭК 10027:1990 Информационная технология. Структура системы словарей информационных ресурсов (IRDS) (см. [11]);

ИСО/МЭК 10728:1993 Информационная технология. Интерфейс услуг системы словарей информационных ресурсов (IRDS) (см. [12]).

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

B.1 Цель

Приложение содержит информацию о принятых и разрабатываемых стандартах JTC 1/SC21/WG3 (Подкомитет ИСО ТК1 по информационным технологиям), связанных с эталонной моделью управления данными, описанной в настоящем стандарте. Настоящее приложение включает в себя описание взаимосвязи упомянутых стандартов с моделью и приводит краткий обзор средств и ограничений, применяемых в эталонной модели управления данными.

B.2 Языки базы данных

В.2.1 Язык базы данных SQL

Язык базы данных SQL (см. ИСО/МЭК 9075 (все части) [1]-[9]) — стандартный язык, который устанавливает синтаксис и семантику утверждений для определения и манипулирования установленными типами данных, процессами транзакций и управления доступом, которые поддерживают использование баз данных SQL.

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

Термины SQL — это термины прикладного использования эталонной модели управления данными, рассматриваемой в разделе 6. Термины, используемые в стандарте на SQL, связаны с терминами, используемыми в разделе 6 настоящего стандарта следующим образом (таблица В.1):

Таблица В.1 — Соотношение терминов: раздел 6 — SQL*/RMDM**

Термин эталонной модели управления данными

События элемента управления источника данных (Data Source Control) в ASP.NET 2.0

Written on 18 Января 2009 . Posted in ASP.NET

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

Модель события элемента управления источником данных (Data Source Control)

Элементы управления SqlDataSource и ObjectDataSource предоставляют методы для выборки, вставки, обновления и удаления данных — Select(), Insert(), Update() и Delete(). Данные методы могут быть вызваны программным путем или, что является частым случаем, могут быть автоматически из элемента управления данными, который был привязан к элементу управления источником данных. Когда вызывается метод Select() элемента управления SqlDataSource он устанавливает соединение с конкретной базой данных, запускает указанный запрос SelectCommand, и возвращает результат в DataView либо DataReader (в зависимости от значения DataSourceMode property). Когда вызывается метод Select() для ObjectDataSource, настроенному объекту приписывается значение и вызывается указанный метод. Результат данного метода затем возвращается из метода Select().

Несмотря на внутренние различия в методе Select() для элементов управления SqlDataSource и ObjectDataSource, оба элемента управления обладают одной и той же моделью события. Для четырех методов — Select(), Insert(), Update() и Delete() — элементы управления SqlDataSource и ObjectDataSource вызывают события до и после действия. Одно событие предшествует действию, а другое следует за ним. События названы соответственно прошедшему и настоящему временам. Событие выборки вызывается до того как получены данные как только была выполнена нижележащая команда выборки (select) — вызывается событие выборки. Следующая диаграмма демонстрирует данную модель.

Данная диаграмма показывает модель метода Select() элемента ObjectDataSource. Такая же модель используется для методов Insert(), Update()и Delete() и для элемента управления SqlDataSource. Хотя принцип одинаков как для элемента SqlDataSource, так и для ObjectDataSource, реализация все же отличается.

Исследуем события элемента управления SqlDataSource, происходящие до выполнения действия

Обработчикам событий элемента управления SqlDataSource,происходящих до действий, кроме прочих битов информации передается ссылка на объект Command, используемый для выполнения действия базы данных. Объект Command содержит информацию о той команде, которую нужно выполнить (посредством свойства CommandText) и которая будет нестандартным SQL-выражением либо названием хранимой процедуры. Она также будет иметь набор Parameters , который хранит параметры, используемые в запросе.

Если вам необходимо манипулировать параметрами, используемыми в выражениях SELECT, INSERT, UPDATE и DELETE, SelectCommand следующим образом: то вы можете сделать это посредством соответствующего обработчика события, выполняемого до действия. К примеру, представьте, что элемент управления SqlDataSource настроен с

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

Для элемента управления SqlDataSource вы можете осуществить доступ к значению параметра при помощи e.Command.Parameters(«parameterName») для того, чтобы программно настроить (либо изменить) параметр @Salary:

Приложение к данной статье предоставляет вспомогательный метод для отображения CommandText и всех параметров принадлежащих Command при получении либо изменении данных используя элемент управления SqlDataSource. Данный результат может оказаться очень полезным при отладке.

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

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

Исследуем события элементов управления ObjectDataSource и SqlDataSource, происходящие после выполнения действия
После того, как было завершено определенное действие, элементы управления SqlDataSource и ObjectDataSource вызывают свои соответствующие события (Selected, Inserted, Updated или Deleted). В обработчике события, следующего за действием, число кортежей, подверженных изменению, сообщается после того, как произойдет исключение. Обработчику события элемента ObjectDataSource, происходящего после действия, также передается значение, полученное от вызванного метода библиотеки объектов (если есть такой). Исключение может произойти в случае, если база данных пала, было использовано неправильное значение параметра, была нарушена ссылочная целостность, либо по какой-нибудь другой причине. Более того, если было обнаружено исключение, то свойство ExceptionHandled может быть установлено в значение True, чтобы известить о том, что исключение может быть обработано.

Вывод

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

Что такое «система управления мастер-данными» и зачем она нужна

Какие бывают данные

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

Ниже представлены 5 ключевых типов:

1. Метаданные (Metadata);
2. Референс-данные (Reference data);
3. Мастер-данные (Master data);
4. Транзакционные данные (Transactional data);
5. Исторические данные (Historical data).

Метаданные – это данные о данных. Они нужны для понимания и определения, какими данными оперирует предприятие. Метаданные определяют структуры, типы данных, доступы к ним и т.д. Существуют различные схемы для описания метаданных. Например, для описания структуры XML-документа может применяться XSD-схема, для описания веб-сервиса – WSDL-схема.

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

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

Илон Маск рекомендует:  Бесплатный курс «Основы HTML и CSS»

Транзакционные данные – это данные, которые образовались в результаты выполнения предприятием каких-либо бизнес-транзакций. Например, для коммерческого предприятия: продажи продуктов и услуг, закупки, поступления/списания денежных средств, поступления на склад и т.п. Обычно такие данные базируются в системе управления ресурсами предприятия (ERP) или других отраслевых системах. Естественно, транзакционные системы широко используют мастер-данные при выполнении транзакций.

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

Cистемы управления мастер-данными

Прежде чем перейти к системе управления мастер-данными, определим, что такое управление мастер-данными вообще.

Управление мастер-данными (Master Data Management, MDM) – дисциплина, которая работает с мастер-данными в целях создания «золотой записи», то есть целостного и всестороннего представления о мастер-сущности и взаимосвязях, эталона мастер-данных, который используются всем предприятием, а иногда и между предприятиями для упрощения обмена информацией.

Специализированные системы управления мастер данными (MDM-системы) автоматизируют все аспекты этого процесса и являются «авторитетным» источником мастер-данных масштаба предприятия. Часто MDM-системы управляют также и референс-данными.

Ситуация, когда MDM-система является единственным источником мастер-данных, все изменения вносятся в MDM-систему и только потом передаются в системы-потребители, называется «системой записей». Это идеальная ситуация для управления мастер-данными. Однако в реальной жизни все не так просто: MDM-система не всегда будет являться «системой записей». Из-за особенностей бизнес-процессов конкретного предприятия, технических сложностей конкретных систем и т.д., приходится создавать «копии» мастер-записей. Система, в которой содержится копия мастер-данных, называется «системой ссылок». Чтобы не терять управляемости, «система ссылок» обязательно должна находиться под управлением и синхронизироваться с «системой записей».

Три измерения MDM-систем


Рассмотрим MDM–систему в трех измерениях:

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

Рассмотрим подробнее эти измерения.

Домены

В контексте управления мастер-данными под доменом понимается конкретная область мастер-данных. Самые распространённые домены мастер-данных – это домен клиентов и домен продуктов. В западной литературе сложились устоявшиеся термины для управления мастер-данными в рамках этих доменов: Customer Data Integration (CDI) – для домена клиентов и Product Information Management (PIM) – для домена продуктов.

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

К PIM традиционно относятся: продукция, товары, материалы, услуги, работы и т.д.
Есть много общего в подходах к управлению мастер-данными CDI и PIM, но есть также и много отличий. Например, при дедубликации клиентских сущностей в большинстве случаев выполняется простой синтаксический анализ атрибутов сущностей и их сопоставление на основе вероятностных алгоритмов, в то время как в продуктовом домене проводится семантический/онтологический анализ атрибутов с подключением механизмов самообучения. Кроме того, в продуктовом домене у сущностей в зависимости от выбранной категории могут сильно различаться атрибуты (например, у ноутбуков свой набор атрибутов, а у стиральных машинок – свой). Все эти особенности различных доменов должны поддерживаться MDM-системами.

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

Методы использования

Методы использования MDM (Method of use) определяют то, для чего MDM система будет использоваться на предприятии. Иными словами, кто будет потребителем мастер-данных (естественно, их может быть несколько).

Основных методов использования три:

1. Аналитический (Analytical)
2. Операционный (Operational)
3. Коллективный (Collaborative)

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

Операционный метод использования позволяет собирать, изменять и использовать мастер-данные в процессе выполнения бизнес-транзакций (операций) и служит для поддержки семантической согласованности мастер-данных в рамках этих операций внутри всех операционных приложений. Фактически, в этом случае MDM функционирует как OLTP-система, которая отрабатывает запросы от других операционных приложений или пользователей. Работа в таком режиме зачастую требует построения единого интеграционного ландшафта с использованием принципов сервис-ориентированной архитектуры (SOA) и применением инструментария сервисной шины предприятия (ESB). Идеально, если такие инструменты или входят непосредственно в MDM-систему, или являются ее продолжением (есть вендоры, которые имеют в своей линейке и MDM и ESB-решения, глубоко интегрированные между собой).

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

Стили внедрения

Обычно выделяют три основных стиля внедрения (implementation style):

1. Реестровый (registry);
2. Сосуществующий (coexistence);
3. Транзакционный (transactional).

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

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

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

Заключение

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

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

Язык реляционных запросов SQL. Команды управления данными.

SQL (англ. Structured Query Language — язык структурированных запросов) — универсальный компьютерный язык, применяемый для создания, модификации и управления данными в реляционных базах данных.

SQL является информационно-логическим языком, а не языком программирования. SQL основывается на реляционной алгебре.

Язык SQL делится на три части:

· операторы определения данных (Data Definition Language, DDL)

· операторы манипуляции данными (Data Manipulation Language, DML)

· операторы определения доступа к данным (Data Control Language, DCL)

Преимущества:

· Независимость от конкретной СУБД. Несмотря на наличие диалектов и различий в синтаксисе, в большинстве своём тексты SQL-запросов, содержащие DDL и DML, могут быть достаточно легко перенесены из одной СУБД в другую.

· Наличие стандартов. Наличие стандартов и набора тестов для выявления совместимости и соответствия конкретной реализации SQL общепринятому стандарту только способствует «стабилизации» языка.

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

Недостатки:

· Несоответствие реляционной модели данных. Создатель реляционной модели данных Эдгар Кодд, Кристофер Дейт и их сторонники указывают на то, что SQL не является истинно реляционным языком. В частности они указывают на следующие проблемы SQL:

· Неопределённые значения (nulls)

· Явное указание порядка колонок слева направо

· Колонки без имени и дублирующиеся имена колонок

· Отсутствие поддержки свойства «=»

· Сложность. Хотя SQL и задумывался как средство работы конечного пользователя, в конце концов, он стал настолько сложным, что превратился в инструмент программиста.

· Отступления от стандартов. Несмотря на наличие международного стандарта ANSI SQL-92, многие компании, занимающиеся разработкой СУБД вносят изменения в язык SQL, применяемый в разрабатываемой СУБД, тем самым отступая от стандарта. Таким образом, появляются специфичные для каждой конкретной СУБД диалекты языка SQL.

· Сложность работы с иерархическими структурами. Ранее SQL не предлагал стандартного способа манипуляции древововидными структурами. Некоторые поставщики СУБД предлагали свои решения. Например, Oracle использует выражение «CONNECT BY». В настоящее время в качестве стандарта принята рекурсивная конструкция «WITH».

Условно команды SQL можно разделить на четыре группы:

· команды определения данных;

· команды манипулирования данными;

· команды управления данными;

· команды управления транзакциями.

Команды управления данными

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

Операторы управления данными включают в себя применяемые для предоставления и отмены полномочий команды GRANT и REVOKE, а также команду SET ROLE, которая разрешает или запрещает роли для текущего сеанса.

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

Привилегии:

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

· RESOURCE разрешает пользователю создавать объекты базы данных, включая таблицы и индексы.

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

Например: GRANT DBA TO SYSADM IDENTIFIED BY SYSTEM

Аналогично, если пользователю предоставляются полномочия на объект, то параметр GRANT позволяет передать эту возможность предоставления полномочий другим пользователями и ролям:

GRANT SELECT, INSERT, UPDATE, DELETE ON customer ТО jkennedy WITH GRANT OPTION

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

Отмена привилегий осуществляется с помощью команды REVOKE. Можно отменить общие привилегии пользователя или же привилегии на указанную таблицу. Например:

REVOKE CREATE TABLE FROM aligncoln

REVOKE placeorders FROM orderentry

REVOKE SELECT ON customer FROM tjefferson

С помощью команды REVOKE можно задать отменяемое полномочие или роль. Предложение FROM позволяет указать пользователя или роль, для которых отменяются полномочия. Ключевое слово ALL позволяет отменить все объектные полномочия:

REVOKE ALL ON customer FROM rnixon

Команда SQL SET ROLE разрешает или запрещает роли в текущем сеансе. С помощью ролей администратор может значительно упростить управление полномочиями.

Последнее изменение этой страницы: 2020-01-25; Нарушение авторского права страницы

Управление данными
Data management

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

Содержание

Управление данными (англ. data management) — процесс, связанный с накоплением, организацией, запоминанием, обновлением, хранением данных и поиском информации.

К управлению данными относятся

  • Анализ данных
  • Моделирование данных
  • Управление базами данных
  • Работа с хранилищами данных
  • Извлечение, преобразование и загрузка данных
  • Добыча данных
  • Обеспечение качества данных
  • Защита данных
  • Шифрование данных
  • Управление метаданными (репозиториями данных)
  • Архитектура данных

2020: Эффективное управление данными увеличивает продажи в 3 раза

Согласно исследованиям Experian, в которых приняли участие 1400 организаций из восьми стран мира, компании все больше осознают экономический потенциал информации: по мнению 79% опрошенных, к концу десятилетия данные о клиенте будут определять большую часть решений о продаже. Однако при этом почти все опрошенные — 90% — по-прежнему считают, что им недостает конструктивного подхода к эффективному управлению данными.

В среднем, почти 25% данных по клиентам содержать неточности. Среди наиболее распространенных ошибок:


  • неполные или отсутствующие данные
  • устаревшие сведения
  • дупликация данных
  • противоречивая информация

Согласно исследованию Experian, компании полагают, что могли бы увеличить продажи почти на 29% при наличии точных клиентских данных.

Согласно оценкам, в 2012 г. каждый день создавался впечатляющий объем данных –2,5 квинтильона байтов – и это в то время, когда мобильная связь, согласно оценкам, охватила 61% населения земного шара. Если исходить из того, что к 2020 г. эта цифра возрастет до 70%, становится очевидно, что объем данных в ближайшие годы будет расти экспоненциально.

Такой «взрывной» рост данных является вызовом для компаний. Как отметили 84% респондентов, их организация в настоящее время считает данные неотъемлемым компонентом бизнес-стратегии. В связи с этим 82% компаний в ближайшие пять лет планируют принять на работу специалистов по данным. Как установило предыдущее исследование Experian, сегодня растет значимость директора по данным (CDO), который развивает работу с данными в рамках стратегической деятельности компании, обеспечивая улучшение финансовых результатов.

Управление данными также усложняется из-за растущих объемов информации и изменений в использовании каналов связи. По словам 39% респондентов (против 10% в прошлом году), их организация имеет 50 или более баз контактов. Кроме того, использование социальных сетей за последние 12 месяцев выросло на 81%.

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

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

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

2013: Специфика финансовых организаций

В декабре 2013 года Qlik (QlikTech) обнародовала результаты исследования, которое показало: несмотря на то, что после мирового финансового кризиса управление данными приобрело особое значение, более чем две трети (63%) руководителей финансовых компаний не считают необходимым рассматривать этот вопрос на уровне высшего руководства.

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

Помимо беспрецедентного увеличения объема ежедневно обрабатываемых данных, в действие введено множество нормативно-правовых актов, связанных с управлением данными – таких как закон Сарбейнза-Оксли, Правило 17а-4 Комиссии по ценным бумагам США, стандарты Базель III и Solvency II, а также принципы Базельского комитета по банковскому надзору BCBS 239 (агрегирование данных о рисках). В ответ на это финансовые учреждения должны были сформировать общие подходы в вопросах архитектуры и моделирования данных; решение этой задачи и обеспечивает управление данными.

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

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

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

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

НазадВведение в структурированный язык

Основные понятия

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

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

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

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

Реляционные базы данных

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

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

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

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

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

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

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

Реляционные связи между таблицами баз данных

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

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

Выделяют три разновидности связи между таблицами базы данных :

  • «один–ко–многим»;
  • «один–к–одному»;
  • «многие–ко–многим».

Отношение «один–ко–многим»

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

Отношение «один–к–одному»

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

Отношение «многие–ко–многим»

Отношение «многие–ко–многим» применяется в следующих случаях:

  • одной записи в родительской таблице соответствует более одной записи в дочерней;
  • одной записи в дочерней таблице соответствует более одной записи в родительской.

Всякую связь «многие–ко–многим» в реляционной базе данных необходимо заменить на связь «один–ко–многим» (одну или более) с помощью введения дополнительных таблиц .

Стандарт и реализация языка SQL

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

Одним из языков, появившихся в результате разработки реляционной модели данных, является язык SQL (Structured Query Language), который в настоящее время получил очень широкое распространение и фактически превратился в стандартный язык реляционных баз данных . Стандарт на язык SQL был выпущен Американским национальным институтом стандартов (ANSI) в 1986 г., а в 1987 г. Международная организация стандартов (ISO) приняла его в качестве международного. Нынешний стандарт SQL известен под названием SQL/92.

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

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

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

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

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

Введение в технологию клиент-сервер

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

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

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

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

Архитектура клиент-сервер обладает рядом преимуществ:

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

Дальнейшее расширение двухуровневой архитектуры клиент-сервер предполагает разделение функциональной части прежнего, «толстого» (интеллектуального) клиента на две части. В трехуровневой архитектуре клиент-сервер «тонкий» (неинтеллектуальный) клиент на рабочей станции управляет только пользовательским интерфейсом, тогда как средний уровень обработки данных управляет всей остальной логикой приложения. Третий уровень – сервер базы данных . Эта трехуровневая архитектура оказалась более подходящей для некоторых сред – например, для сетей Internet и intranet, где в качестве клиента может выступать обычный Web-браузер.

Типы команд SQL

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

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

Основные категории команд языка SQL:

  • DDL – язык определения данных;
  • DML – язык манипулирования данными;
  • DQL – язык запросов ;
  • DCL – язык управления данными;
  • команды администрирования данных;
  • команды управления транзакциями

Определение структур базы данных (DDL)

Язык определения данных (Data Definition Language, DDL) позволяет создавать и изменять структуру объектов базы данных , например, создавать и удалять таблицы . Основными командами языка DDL являются следующие: CREATE TABLE , ALTER TABLE , DROP TABLE , CREATE INDEX , ALTER INDEX , DROP INDEX .

Манипулирование данными (DML)

Язык манипулирования данными (Data Manipulation Language, DML) используется для манипулирования информацией внутри объектов реляционной базы данных посредством трех основных команд: INSERT , UPDATE , DELETE .

Выборка данных (DQL)

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

Язык управления данными (DCL — Data Control Language)

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

Команды администрирования данных

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

Команды управления транзакциями

Существуют следующие команды, позволяющие управлять транзакциями базы данных : COMMIT , ROLLBACK , SAVEPOINT , SET TRANSACTION .

Преимущества языка SQL

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

Основные достоинства языка SQL заключаются в следующем:

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

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

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

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

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

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

Язык SQL используется в других стандартах и даже оказывает влияние на разработку иных стандартов как инструмент определения (например, стандарт Remote Data Access, RDA). Создание языка способствовало не только выработке необходимых теоретических основ, но и подготовке успешно реализованных технических решений. Это особенно справедливо в отношении оптимизации запросов , методов распределения данных и реализации средств защиты. Начали появляться специализированные реализации языка, предназначенные для новых рынков: системы управления обработкой транзакций (OnLine Transaction Processing, OLTP ) и системы оперативной аналитической обработки или системы поддержки принятия решений (OnLine Analytical Processing, OLAP ). Уже известны планы дальнейших расширений стандарта , включающих поддержку распределенной обработки, объектно-ориентированного программирования, расширений пользователей и мультимедиа.

© Компания Либэр 1993-2020. Все права защищены
Условия использования

Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL