на каком уровне не создается словарь данных
На каком уровне не создается словарь данных
На первом этапе проектирования базы данных необходимо собрать сведения о предметной области, в том числе о назначении, способах использования и о структуре данных, а по мере развития проекта осуществлять централизованное накопление информации о концептуальной, логической, внутренней и внешних моделях данных. Словарь данных является как раз тем средством, которое позволяет при проектировании, эксплуатации и развитии базы данных поддерживать и контролировать информацию о данных.
При сборе информации о данных следует установить правила присвоения имен элементам, добиться однозначного толкования различными подразделениями назначения источников и соглашений по присвоению имен, сформулировать приемлемые для всех пользователей описания элементов данных и выявить синонимы. Этот процесс включает несколько итераций и связан с необходимостью разрешения конфликтных ситуаций. Отдельные подразделения подчас переоценивают свою роль на предприятии, что приводит при разработке информационной системы к конфликтам. Разработчику в таких случаях придется выступать в роли арбитра. Если вам не по душе слушать крики: «Судью на мыло!», то для обеспечения эффективного сбора и накопления информации о данных желательно, чтобы все, кто имеет отношение к базе данных, пользовались автоматизированным словарем данных.
Словарь данных содержит информацию об источниках, форматах и взаимосвязях между данными, их описания, сведения о характере использования и распределении ответственности. Словарь данных можно рассматривать как «Метабазу данных», в которой хранится информация о базе данных.
Одно из главных назначений словаря данных состоит в документировании данных. Так как база данных обслуживает множество пользователей, крайне необходимо, чтобы они правильно понимали, что представляют собой данные.
Неавтоматизированный словарь данных не может обеспечить получение по-разному отсортированных списков элементов данных, которыми пользуются разработчики. Один и тот же элемент может неодинаково
использоваться в различных приложениях. На ранней стадии проектирования выявляются далеко не все связи между данными. Впоследствии обнаруживается, что данные применяются в разнообразных приложениях. Они могут встречаться, например, во входных и выходных форматах, связанных между собой, и всякий раз рассматриваются в различных контекстах. Чтобы учесть все возможные ограничения, необходимо приложить значительные усилия. Процесс проектирования же становится в таком случае трудно управляемым. Гораздо проще организовать и управлять разработкой с помощью автоматизированного словаря данных.
Для успешного применения словаря данных при разработке системы следует централизовать накопление информации в этом едином источнике, из которого программисты смогут копировать описания структур данных и включать их в свои программы на всех этапах проектирования. В случае применения «ручного» или не интегрированного словаря в нем время от времени может происходить нарушение непротиворечивости информации по отношению к фактическому состоянию системы.
В идеальном случае интерфейс между СУБД и словарем данных должен обеспечивать доступ системы словаря к справочникам СУБД, в которых хранится информация о ее текущем состоянии. Модификация типов данных может производиться только после того, как это будет зарегистрировано в словаре данных. Обновление самих данных допускается лишь после проверки их корректности средствами СУБД. Таким образом, словарь данных, СУБД и база данных образуют замкнутый контур.
В идеале словарь данных должен быть неотъемлемой составной частью всей системы обработки данных. За ввод данных в словарь ответственность несет администратор БД. Поскольку словарь данных является центральным звеном системы, необходимо постоянно поддерживать его копию, которая может использоваться для восстановления словаря после возникновения отказа всей системы или в случае непреднамеренного разрушения его рабочей версии. За сохранность словаря данных как жизненно важной части системы с базой
Данных полностью отвечает администрация базы данных.
Если словарь данных применяется для разграничения доступа к базе данных, то доступ к нему надо также разграничить. Следует строго ограничить круг лиц, которым разрешено модифицировать словарь данных. В отношении хранимой в словаре информации должен быть реализован режим секретности.
зМБЧБ 15. уМПЧБТШ ДБООЩИ MySQL
MySQL Server ФЕРЕТШ ЧЛМАЮБЕФ ФТБОЪБЛГЙПООЩК УМПЧБТШ ДБООЩИ, ЛПФПТЩК ИТБОЙФ ЙОЖПТНБГЙА ПВ ПВЯЕЛФБИ ВБЪЩ ДБООЩИ. ч РТЕДЩДХЭЙИ ЧЩРХУЛБИ MySQL ДБООЩЕ П УМПЧБТЕ ИТБОЙМЙУШ Ч НЕФБЖБКМБИ У ДБООЩНЙ Й ОЕФТБОЪБЛГЙПООЩИ ФБВМЙГБИ.
ьФБ ЗМБЧБ ПРЙУЩЧБЕФ ПУОПЧОЩЕ ПУПВЕООПУФЙ, ЧЩЗПДХ, ТБЪМЙЮЙС Ч ЙУРПМШЪПЧБОЙЙ Й ПЗТБОЙЮЕОЙС УМПЧБТС ДБООЩИ. дМС ЙОЖПТНБГЙЙ П ДТХЗЙИ ЧПЪНПЦОПУФСИ УМПЧБТС ДБООЩИ, ПВТБФЙФЕУШ Л ТБЪДЕМХ Data Dictionary Notes ТЕУХТУБ MySQL 8.0.0 Release Notes.
InnoDB РТПДПМЦБЕФ ЙУРПМШЪПЧБФШ УПВУФЧЕООЩК УМПЧБТШ ДБООЩИ Ч MySQL 8.0.0.
чЩЗПДБ УМПЧБТС ДБООЩИ MySQL ЧЛМАЮБЕФ:
дБООЩЕ, ЧЛМАЮЕООЩЕ УЕТЧЕТПН Ч УМПЧБТШ, ЧМЕЛХФ ЪБ УПВПК ОЕЛПФПТЩЕ ПВЭЙЕ ПРЕТБГЙПООЩЕ ТБЪМЙЮЙС; УН. ТБЪДЕМ 15.6. лТПНЕ ФПЗП, ДМС ПВОПЧМЕОЙК ДП MySQL 8.0 ПФ MySQL 5.7, РТПГЕДХТБ ПВОПЧМЕОЙС ОЕУЛПМШЛП ПФМЙЮБЕФУС ПФ РТЕДЩДХЭЕЗП ТЕМЙЪБ Й ФТЕВХЕФ, ЮФПВЩ чЩ РТПЧЕТЙМЙ ЗПФПЧОПУФШ ПВОПЧМЕОЙС УЧПЕК ХУФБОПЧЛЙ, РТПЧЕТСС ПРТЕДЕМЕООЩЕ РТЕДРПУЩМЛЙ. дМС РПМХЮЕОЙС ДПРПМОЙФЕМШОПК ЙОЖПТНБГЙЙ, УН. ТБЪДЕМ 2.10.1.
15.1. уИЕНБ УМПЧБТС ДБООЩИ
15.2. хДБМЕОЙЕ ПУОПЧБООПЗП ОБ ЖБКМБИ ИТБОЕОЙС НЕФБДБООЩИ
ч РТЕДЩДХЭЙИ ЧЩРХУЛБИ MySQL ДБООЩЕ П УМПЧБТЕ ЮБУФЙЮОП ИТБОЙМЙУШ Ч НЕФБЖБКМБИ У ДБООЩНЙ. рТПВМЕНЩ У ПУОПЧБООЩН ОБ ЖБКМБИ ИТБОЕОЙЕН НЕФБДБООЩИ ЧЛМАЮБМЙ ДПТПЗЙЕ РТПУНПФТЩ ЖБКМБ, ЧПУРТЙЙНЮЙЧПУФШ Л УЧСЪБООЩН У ЖБКМПЧПК УЙУФЕНПК ПЫЙВЛБН, УМПЦОПНХ ЛПДХ ДМС ФПЗП, ЮФПВЩ ПВТБВПФБФШ ТЕРМЙЛБГЙЙ Й УФБФХУЩ ПФЛБЪБ, Й ОЕИЧБФЛХ ТБУЫЙТСЕНПУФЙ, ЛПФПТБС НЕЫБМБ ДПВБЧМСФШ НЕФБДБООЩЕ ДМС ОПЧЩИ ПУПВЕООПУФЕК Й ПФОПУЙФЕМШОЩИ ПВЯЕЛФПЧ.
хРПНСОХФЩЕ ОЙЦЕ НЕФБЖБКМЩ У ДБООЩНЙ ХДБМЕОЩ ЙЪ MySQL. еУМЙ ОЕ ХЛБЪБОП ЙОПЕ, ДБООЩЕ, ТБОЕЕ УПИТБОЕООЩЕ Ч НЕФБЖБКМБИ У ДБООЩНЙ, ФЕРЕТШ ИТБОСФУС Ч ФБВМЙГБИ УМПЧБТС ДБООЩИ.
15.3. фТБОЪБЛГЙПООПЕ ИТБОЕОЙЕ ДБООЩИ УМПЧБТС
15.4. лЬЫ ПВЯЕЛФПЧ УМПЧБТС
лЬЫ ПВЯЕЛФПЧ УМПЧБТС ЬФП УПЧНЕУФОП ЙУРПМШЪХЕНЩК ЗМПВБМШОЩК ЛЬЫ, ЛПФПТЩК ИТБОЙФ ПВЯЕЛФЩ УМПЧБТС ДБООЩИ, Л ЛПФПТЩН ТБОЕЕ РПМХЮБМЙ ДПУФХР, Ч РБНСФЙ, ЮФПВЩ ЧЛМАЮЙФШ РПЧФПТОПЕ ЙУРПМШЪПЧБОЙЕ ПВЯЕЛФБ Й НЙОЙНЙЪЙТПЧБФШ ДЙУЛПЧЩК ЧЧПД/ЧЩЧПД. рПДПВОЩК ДТХЗЙН НЕИБОЙЪНБН ЛЬЫБ, ЙУРПМШЪХЕНЩН MySQL, ЛЬЫ ПВЯЕЛФПЧ УМПЧБТС ЙУРПМШЪХЕФ УФТБФЕЗЙА LRU ДМС УПИТБОЕОЙС РПУМЕДОЙИ ЙУРПМШЪПЧБООЩИ ПВЯЕЛФПЧ Ч РБНСФЙ.
лЬЫ ПВЯЕЛФПЧ УМПЧБТС ЧЛМАЮБЕФ ТБЪДЕМЩ ЛЬЫБ, ЛПФПТПЕ ИТБОЙФ ТБЪМЙЮОЩЕ ФЙРЩ ПВЯЕЛФПЧ. оЕЛПФПТЩЕ РТЕДЕМЩ ТБЪНЕТПЧ ТБЪДЕМЕОЙС ЛЬЫБ ЛПОЖЙЗХТЙТХЕНЩ.
15.5. йОФЕЗТБГЙС INFORMATION_SCHEMA Й УМПЧБТС ДБООЩИ
у ЧЧЕДЕОЙЕН УМПЧБТС ДБООЩИ УМЕДХАЭЙЕ ФБВМЙГЩ INFORMATION_SCHEMA ПУХЭЕУФЧМЕОЩ ЛБЛ РТЕДУФБЧМЕОЙС ФБВМЙГ УМПЧБТС ДБООЩИ:
15.6. тБЪМЙЮЙС Ч ЙУРПМШЪПЧБОЙЙ УМПЧБТС ДБООЩИ
йУРПМШЪПЧБОЙЕ ДБООЩИ, ЧЛМАЮЕООЩИ Ч УМПЧБТШ УЕТЧЕТПН MySQL, ЧМЕЮЕФ ЪБ УПВПК ОЕЛПФПТЩЕ ПРЕТБГЙПООЩЕ ТБЪМЙЮЙС РП УТБЧОЕОЙА У УЕТЧЕТПН, Х ЛПФПТПЗП ОЕФ УМПЧБТС ДБООЩИ.
15.7. пЗТБОЙЮЕОЙС УМПЧБТС ДБООЩИ
ьФПФ ТБЪДЕМ ПРЙУЩЧБЕФ ЧТЕНЕООЩЕ ПЗТБОЙЮЕОЙС УМПЧБТС ДБООЩИ MySQL.
| оБКДЙ УЧПЙИ ЛПММЕЗ! |
чЩ НПЦЕФЕ ОБРТБЧЙФШ РЙУШНП БДНЙОЙУФТБФПТХ ЬФПК УФТБОЙЮЛЙ, бМЕЛУЕА рБХФПЧХ. 
Словарь данных
Словарь данных, описанный в Словаре вычислений от IBM (IBM Dictionary of Computing) как «центральное хранилище информации о данных, такой как значение, взаимосвязи с другими данными, их иcточник, применение и формат.» [1] Термин может иметь одно из близких по смыслу значений, относясь к базам данных и СУБД:
Содержание
Документация словаря данных
Пользователи баз данных и разработчики приложений могут получить выгоду от единого стандартизированного документа словаря данных, который перечисляет организацию, содержимое, соглашения по одной или более баз данных. [2] Это обычно включает в себя имена и описания различных таблиц и полей в каждой базе данных, дополнительные детали такие, как тип и длина каждого элемента данных. Не существует универсального стандарта, описывающего уровень детализации в подобном документе, но есть основное описание метаданных о структуре базы данных, а не о самих данных. Документ словаря данных также может включать в себя дополнительную информацию, описывающую кодирование элементов данных. Одним из преимуществ хорошо спроектированного документа словаря данных является то, что он помогает упорядочить структуру базы данных или большого комплекса распределенных баз данных. [3]
Словарь данных как промежуточное ПО
В области создания приложений для баз данных, может быть полезным добавление дополнительного программного слоя словаря данных, то есть подпрограммного ПО, который будет взаимодействовать с нижележащим словарем данных СУБД. Такой «высокоуровневый» словарь данных может обеспечить дополнительные возможности и степень гибкости, который обойдет ограничения естественного «низкоуровневого» словаря данных, чье главное назначение заключается в поддержке основных функций СУБД, а не требований обычных приложений. Например, высокоуровневый словарь данных может реализовывать альтернативные ER-модели данных, приспособленных под различные приложения, которые совместно используют распространенные базы данных. [4] Расширения словаря данных также могут помочь и в области оптимизации запросов в распределенных базах данных. [5]
Разработка словаря данных для БД
РЕАЛИЗАЦИЯ БАЗЫ ДАННЫХ
Методика реализации БД
Исходной информацией для создания приложения является предприятие или его фрагмент, который задан в качестве описания объекта автоматизации для выполнения КП. Основными исходными данными для разработки БД является:
1. Требования к БД, которые определены в ТЗ;
2. Документы или та информация об объекте, которые должны храниться в БД. В идеальном случае вся информация должна храниться в БД или формироваться на ее основе;
3. Задачи, которые необходимо реализовать в рамках приложения. В общем случае задачи обычно накладывают некоторые ограничения на перечень хранимой БД, информации. Это вызвано тем, что задачи для автоматизации только частично охватывают существующие в объекте документы.
Процессы реализации БД включают 4 группы объектов:
1. Процесс «Определение и анализ требования к БД»;
2. Процессы проектирования БД;
3. Процессы создания БД;
4. Процесс проверки БД.
Рисунок 2.1 – Процессы реализации БД
Разработка словаря данных для БД
Для каждого выходного документа был создан локальный СД. В результате проведения анализа перечня данных из входных документов и перечня данных из СД – определился общий СД, который содержит определение для всех данных из СД источников данных (см. табл. 2.1 – 2.8).
Таблица 2.2 Словарь данных БД для документа «Отче от рабочих местах работников предприятия»
| № п/п | Источник данных | Идентификатор данных | Назначение данных | Диапазон изменения | Тип данных | Вид данных | Примечание |
| ДО.5 | Nomer_otd | Номер отдела | До 6 цифр | Целое | У | ||
| Nomer_kom | Номер комнаты | До 6 цифр | Целое | У | |||
| N_rab_m | Номер рабочего места | До 6 цифр | Целое | У | |||
| FIO_rab | ФИО работника | До 60 символов | Симв. | У |
Таблица 2.3 Словарь данных БД для документа «Отчет о ПО»
| № п/п | Источник данных | Идентификатор данных | Назначение данных | Диапазон изменения | Тип данных | Вид данных | Примечание |
| ДО.6 | Name | Наименование | До 60 символов | Симв. | У | ||
| Inv_Nomer | Инвентарный номер | До 6 цифр | Целое | У | |||
| Versia | Версия | До 10 цифр | Целое | М | |||
| Postav | Поставщик | До 60 символов | Симв. | М | |||
| Nal_lic | Наличие лицензии | До 6 символов | Силв. | У | |||
| Kol_copy | Количество копий | До 100 цифр | Целое | У | |||
| Date_post | Дата поставки | До 9 цифр | Целое |
Таблица 2.4 Словарь данных для документа «Отчет о ТС и их размещении по рабочим местам»
| № п/п | Источник данных | Идентификатор данных | Назначение данных | Диапазон изменения | Тип данных | Вид данных | Примечание |
| ДО.7 | Name | Наименование | До 60 символов | Симвл. | У | ||
| Nomer_kom | Номер комнаты | До 6 цифр | Целое | У | |||
| Nomer_etaj | Номер этажа | До 100 цифр | Целое | У | |||
| Nomer_rab_mesta | Номер рабочего места | До 6 цифр | Целое | У | |||
| Inv_Nomer | Инвентарный номер | До 6 цифр | Целое | У | |||
| Marka | Марка | До 20 символов | Симвл. | У | |||
| Date_expl | Дата ввода в эксплуатацию | До 9 цифр | Целое |
Таблица 2.5 Словарь данных для документа «Отчет о размещении ПО по ТС»
| № п/п | Источник данных | Идентификатор данных | Назначение данных | Диапазон изменения | Тип данных | Вид данных | Примечание |
| ДО.8 | Name | Наименование | До 60 символов | Симвл. | У | ||
| Inv_nomer | Инвентарный номер | До 6 цифр | Целое | У | |||
| Spisok_PO | Список ПО | До 10 символов | Симвл. | ||||
| Name_PO | Наименование ПО | До 60 символов | Симв. | У | |||
| Inv_nomerPO | Инвентарный номер ПО | До 6 цифр | Целое | У | |||
| Date | Дата | До 9 цифр | Целое |
Таблица 2.6 Словарь данных для документа «Отчет о БД»
| № п/п | Источник данных | Идентификатор данных | Назначение данных | Диапазон изменения | Тип данных | Вид данных | Примечание |
| ДО.9 | Name | Наименование | До 60 символов | Симвл. | У | ||
| Inv_nomer | Инвентарный номер | До 6 цифр | Целое | У | |||
| Date | Дата | До 9 цифр | Целое |
Таблица 2.7 Словарь данных для документа «Отчет о документации»
| № п/п | Источник данных | Идентификатор данных | Назначение данных | Диапазон изменения | Тип данных | Вид данных | Примечание |
| ДО.10 | Name | Наименование | До 60 символов | Симвл. | У | ||
| Date | Дата | До 9 цифр | Целое |
Таблица 2.8 Словарь данных для документа «Отчет о движении ИТ- активов на предприятии»
Организация словаря данных в предметно-ориентированных программных оболочках.
«Словарь данных представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ. »
Г.Н. Калянов
Создание программных комплексов в современном мире информационных технологий требует все большего участия не программирующих пользователей, которые хорошо знают предметную область. Для этого необходим определенный инструментарий, а также описание данных системы, понятное и доступное не только для системных аналитиков и программистов, но и для пользователей. Один из вариантов решения этого вопроса предлагается в данной статье.
Предметно-ориентированная программная оболочка
При проектировании системы необходимо учитывать факторы, связанные с особенностями ее функционирования в конкретной прикладной среде, такие, как класс задач, для которого предназначается система, квалификация и уровень подготовки пользователя, потенциальные возможности системы, адаптация к другим предметным областям, перспективы развития данной предметной области, среды функционирования системы, вопросы ее коммерческого использования. Эти факторы, наряду с возможностями заказчика в финансировании разработки, в обеспечении техникой, инструментальным программным обеспечением, с возможностями программистского коллектива, определяют выбор средств разработки (языка программирования, СУБД).
Разумно предположить, что в процессе разработки приложений будут участвовать как пользователи, так и программисты. Ввиду того, что не все задачи можно решить методом раскрутки на уровне пользователя, система должна предусматривать возможность расширения и на уровне программиста (разработчика).
Уточним понятие расширяемости. В нашем случае это означает, что система имеет ядро, которое решает прикладные базовые задачи в математической и специальной постановке и способно включать новые функции и приложения. Способ (язык) расширения предполагает непосредственно участие пользователя путем формулировки им прикладной задачи. Кроме того, система предполагает расширение ядра на уровне программиста для того, чтобы реализовать достаточно сложные алгоритмы обработки данных. Система предъявляет относительно невысокие требования к квалификации программиста, что позволит успешно работать с ней в организациях, не способных содержать штат высокооплачиваемых программистов.
Пользователю должна быть представлена информация о функциях и процедурах системы, для возможности профессиональной обработки данных. Таким образом, необходимо создать многоуровневый словарь процедур и функций, в целях упрощения их применения пользователем. Пользователь должен иметь возможность настроить свое рабочее место по своему вкусу, поэтому интерфейс системы должен модифицироваться путем добавления нужных и удаления ненужных ему пунктов иерархического меню, процедур и функций. Понятие «расширяемая» для разработчика программных приложений носит куда более широкий характер. В системе реализуется возможность добавлять собственные библиотеки процедур и функций, программные модули и собственно программные приложения.
Пользователю необходимо свободно общаться с доступными ему данными системы. Это достаточно сложная задача. В данной системе ее предлагается решить с помощью многоуровневых словарей данных, которые в зависимости от уровня доступа пользователя будут наглядно представлять ему доступную структуру данных, тем самым упрощая составление запросов и отчетов. Пользователь может составлять свои таблицы, включая их, по своему желанию, для общего пользования, при этом словарь данных будет пополняться.
Определение элементов данных в словаре
Для того, чтобы словарь данных отвечал задаче проектирования, его элементы должны содержать описание потоков, хранилищ, композиции комплексных данных (расчленяющихся на элементарные), движущихся по потокам, и групповых данных хранилищ, описание деталей отношений между хранилищами.
Но конечного пользователя эти проблемы касаются мало, в частности потому, что он либо не принимает вовсе, либо принимает ограниченное участие в разработке ядра системы. В силу того, что пользователь сложной системы работает лишь с ее частью (подсистемой), его в основном интересуют данные, связанные непосредственно с участком работы, за который он отвечает и который обычно имеет локальный характер. Для привлечения пользователя к разработке в части извлечения из него информации о предметной области необходимо, чтобы словарь предметно-ориентированной программной оболочки был структурирован по автоматизированным рабочим местам пользователя (АРМ) и администратора системы. Но это не исключает существования общего словаря данных, здесь лишь отмечается особенность подхода к проблеме его создания в предметно-ориентированной оболочке.
Перейдем теперь к классификации данных с точки зрения доступа к ним пользователя (администратора) системы. Заметим, что идеология предметно-ориентированной оболочки допускает отсутствие описания (отображения) некоторых данных в словаре системы. В основном это данные, связанные с настройкой и жизнеобеспечением системы, защитой от несанкционированного доступа и т.п. Разработчик приложений в этом случае сможет получить необходимую дополнительную информацию особо.
Исходя из концепции предметно-ориентированной оболочки, словарь должен содержать описание структуры данных, определенной разработчиком (поставляемыми с системой) и определенной пользователем, характерной только для конкретного АРМа. Некоторые элементы пользовательской структуры в силу локальности могут не включаться в общий словарь данных.
Введем некоторые определения и обозначения, которые будут использоваться в дальнейшем изложении, а также примем некоторые ограничения, которые служат для упрощения общепринятой концепции словаря данных. Это необходимо для построения модели словаря данных предметно-ориентированной оболочки.
Хранилищем будем называть файл, предназначенный для хранения данных системы, имеющих стандартный формат таблицы, характеризующийся постоянной структурой. Формат записи: «имя хранилища».
Атрибутом хранилища назовем атрибут таблицы (поле). Формат записи: «имя хранилища».»название поля».
Дугой будем называть направленную связь между двумя хранилищами. Формат записи: «имя хранилища»-«имя хранилища».
Атрибуты, включаемые в словарь, подразделяются на первичные и вторичные.
Под первичными данными будем понимать 1) данные хранилищ, полученные в результате первого преобразования внешних входных данных системы в данные формата хранилищ; 2) данные хранилищ, вводимые пользователем вручную.
Под нулевым набором D0 будем понимать первичные данные. Если есть (n-1)-й набор Dn-1, то Dn получается из него применением n-го процесса.
Рис.1.
Обозначим атрибуты хранилищ как узлы графа, тогда получим ациклический граф атрибутов (см.рис. 2). Это объясняется тем, что замкнутый процесс перехода атрибута dikjn в самого себя недопустим. Полученный граф назовем А-графом.
Рис.2.
Будем классифицировать первичные и вторичные данные и разобьем их по группам. Данные, которые могут быть только первичными (входными) подразделяются на
1) группу внешних данных;
Данные второй группы являются базовыми для некоторых операций, поэтому их удобно выделить в особую группу. Пользовательский доступ к ним следует ограничить. Все три группы описываются в словаре системы.
Данные, которые могут быть как первичными, так и вторичными (переходные) имеет смысл заносить в словарь, если они формируются в виде файлов-таблиц.
Исходя из предложенной концепции построения словаря данных видно, что словарь предметно-ориентированной оболочки может не содержать описания всех потоков и хранилищ данных, т.е. с точки зрения классического определения словаря информация в нем будет не полной. Построение по такому словарю системы обычными методами невозможно, но основное его предназначение в том, чтобы облегчить работу пользователя со своим АРМом и помочь ему создать свои запросы и приложения. С другой стороны, словарь, отражающий точку зрения пользователя на предметную область, может служить важным источником знаний о ней в процессе разработки и сопровождения системы.
Для того, чтобы пользователь мог работать со словарем, необходим доступный ему по интерфейсу и множеству используемых понятий инструментарий.
| Атрибут | Название атрибута | Тип | Размер |
| Cod_db | Идентификатор хранилища | N | 5 |
| nam_db | Название хранилища | C | 50 |
| typ_db | Группа хранилища | N | 1 |
| Индексы таблицы: | |||
| Название | Выражение | Связанные таблицы | |
| Cod_db | Список атрибутов хранилищ | Cod_db | |
| nam_db | Граф хранилищ | nam_db | |
Построение реляционной модели словаря предметно-ориентированной оболочки
Для удобства организации пользовательского интерфейса словаря, следует создать таблицу, содержащую список хранилищ системы. В соответствии с распределением хранилищ по группам, кроме обычных атрибутов для подобных таблиц, необходимо хранить признак разбиения.
| Атрибут | Название атрибута | Тип | Размер |
| Cod_db | Идентификатор хранилища | N | 5 |
| Cod_a | Идентификатор атрибута | N | 5 |
| name_pole | Имя атрибута | C | 10 |
| nam_a | Название атрибута | C | 50 |
| typ_а | Группа атрибута | N | 1 |
| type_pole | Тип атрибута | C | 1 |
| len_pole | Размер атрибута | N | 3 |
| len_dec | Размер десятичной части | N | 3 |
| Индексы таблицы: | Название | Выражение | Связанные таблицы |
| Cod_db | Cod_db | Список хранилищ | name_pole |
| Cod_a | Cod_a | Сеть атрибутов | name_pole |
Для хранения атрибутов хранилищ необходимо создать специальную таблицу, которая будет связана с первой таблицей «Список хранилищ» по полю «Идентификатор хранилища». Каждая запись таблицы «Список атрибутов хранилищ» должна содержать код хранилища для каждого атрибута, (таким образом реализуется связь типа «один ко многим»), а также полную информацию о каждом атрибуте хранилища.
| Атрибут | Название атрибута | Тип | Размер |
| Cod_i_db | Идентификатор первичного хранилища | N | 5 |
| Cod_o_db | Идентификатор вторичного хранилища | N | 5 |
| Индексы таблицы: | Название | Выражение | Связанные таблицы |
| Cod_i_db | Cod_i_db | Список хранилищ | (cod_db) |
| Cod_o_db | Cod_o_db | Список хранилищ | (cod_db) |
Для описания потоков данных на уровне хранилищ, необходимо хранить информацию, описывающую граф (см. рис. 1), т.е. таблица «Граф хранилищ» должна иметь ссылку на таблицу «Список хранилищ», а также содержать информацию о направлении потока данных. Исходя из структуры таблицы 1, достаточно хранить код первичного и вторичного хранилищ.
Замечание
Подробное описание построения индексов и обоснование этого построения будет дано при введении операций над словарем.
| Атрибут | Название атрибута | Тип | Размер |
| Cod_i_a | Идентификатор первичного атрибута | N | 5 |
| Cod_o_a | Идентификатор вторичного атрибута | N | 5 |
| Индексы таблицы: | Название | Выражение | Связанные таблицы |
| Cod_i_db | Cod_i_db | Список атрибутов | cod_a |
| Cod_o_db | Cod_o_db | Список атрибутов | cod_a |
Для описания потоков данных на уровне атрибутов необходимо хранить информацию, описывающую А-граф (рис. 2). Таблица «Граф атрибутов» должна иметь ссылку на таблицу «Список атрибутов хранилищ» и содержать информацию о направлении потока данных. Исходя из структуры таблицы 2, достаточно хранить код первичного и вторичного атрибутов.
Рассмотрим теперь операции, которые пользователь может выполнять со словарем данных. Во-первых, это операции, связанные с добавлением, корректировкой и удалением хранилищ из списка, если данные хранилища относятся к группе пользовательских (заметим, что физически хранилища удалятся не будут, удаление производится в представлении пользователя). Во-вторых, это пополнение собственного словаря из общесистемного или из словаря другого пользователя. В-третьих, вывод данных на уровне хранилищ или атрибутов (по желанию), сортируя их по группам входных, выходных данных и, отдельно, справочных и пользовательских. В-четвертых, просматривать потоки по дугам для данного хранилища или получать список хранилищ между конкретным входным и выходным хранилищам. В-пятых, определять для данного хранилища вторичные данные или, что гораздо интереснее, определять первичные для конкретных вторичных данных на уровне хранилищ и атрибутов.
Организация словаря данных осуществляется с помощью графического пользовательского интерфейса. Визуальное представление в виде диаграмм потоков данных и диаграммы «сущность-связь» осуществляется только для администраторов системы с помощью прикладных пакетов типа «ERwin». Реализация данной концепции словаря данных будет осуществляться с помощью СУБД FoxPro 2.6 for Windows 3.1 и выше и СУБД FoxPro 5.0 for Windows 95, а также Windows NT 3.5 и выше.
Литература
1. Бобровски С. Oracle 7 вычисления клиент/сервер М.: «Лори», 1996.
2. Калянов Г.Н. CASE структурный системный анализ. М. «Лори», 1996.
3. Козлинский А.В. CASE-технология: индустриальная разработка систем обработки информации // Компьютерное обозрение. 1993 №1 С.29-40
4. Липаев В.В. Управление разработкой программных комплексов. М.: Финансы и статистика, 1993
5. Фокс Д. Программное обеспечение и его разработка. М.: Мир, 1985.