что такое словарь данных
Словарь данных
Словарь данных, описанный в Словаре вычислений от IBM (IBM Dictionary of Computing) как «центральное хранилище информации о данных, такой как значение, взаимосвязи с другими данными, их иcточник, применение и формат.» [1] Термин может иметь одно из близких по смыслу значений, относясь к базам данных и СУБД:
Содержание
Документация словаря данных
Пользователи баз данных и разработчики приложений могут получить выгоду от единого стандартизированного документа словаря данных, который перечисляет организацию, содержимое, соглашения по одной или более баз данных. [2] Это обычно включает в себя имена и описания различных таблиц и полей в каждой базе данных, дополнительные детали такие, как тип и длина каждого элемента данных. Не существует универсального стандарта, описывающего уровень детализации в подобном документе, но есть основное описание метаданных о структуре базы данных, а не о самих данных. Документ словаря данных также может включать в себя дополнительную информацию, описывающую кодирование элементов данных. Одним из преимуществ хорошо спроектированного документа словаря данных является то, что он помогает упорядочить структуру базы данных или большого комплекса распределенных баз данных. [3]
Словарь данных как промежуточное ПО
В области создания приложений для баз данных, может быть полезным добавление дополнительного программного слоя словаря данных, то есть подпрограммного ПО, который будет взаимодействовать с нижележащим словарем данных СУБД. Такой «высокоуровневый» словарь данных может обеспечить дополнительные возможности и степень гибкости, который обойдет ограничения естественного «низкоуровневого» словаря данных, чье главное назначение заключается в поддержке основных функций СУБД, а не требований обычных приложений. Например, высокоуровневый словарь данных может реализовывать альтернативные ER-модели данных, приспособленных под различные приложения, которые совместно используют распространенные базы данных. [4] Расширения словаря данных также могут помочь и в области оптимизации запросов в распределенных базах данных. [5]
Просто о списках, словарях и множествах или ТОП 5 структур данных
Привет. Ей! Не говорите “Да блин! Я знаю, чем отличается список от вектора, мне не нужна эта статья”. Прошу, загляните под кат и освежите свои знания. Я надеюсь, однако, что вы сможете почерпнуть из этой статьи намного больше и, некоторые, возможно, наконец-то разберутся, почему существует так много типов данных для коллекций объектов.
Введение
Так уж сложилось, что в программировании коллекции представляет много, нет ОЧЕНЬ МНОГО различных сущностей — списки, массивы, вектора, множества, стеки, очереди, ассоциативные массивы и у большинства из этих структур данных есть еще по несколько подвидов.
Должны же быть причины, чтобы для простого представления какой-либо совокупности объектов существовало настолько много различных вариаций.
Должны же быть отличия между списком и массивом? Между ассоциативным массивом и хеш-таблицей?
Коллекция
Для начала — самое скучное (да, я люблю такое). Что такое коллекция вообще?
Коллекция — структура данных (тип, класс, даже лучше сказать интерфейс), которая создана, чтобы содержать в себе некоторое количество объектов (в зависимости от языка и терминологии они должны быть одного типа или могут быть разных типов).
Различные типы коллекций могут быть статическими или динамическими, т.е. изменять свой размер или оставаться постоянными, могут быть упорядоченными (точнее учитывающими порядок элементов) и неупорядоченными (соответственно не учитывающими).
Над коллекциями предусмотрено несколько стандартных операций (сейчас мы поговорим о мутабельных, т.е. изменяемых коллекциях), таких как: получение размера, добавление элемента, удаление элемента, поиск (есть какой-либо элемент в коллекции или нет), их очень много.
Ладно, свой негласный долг я выполнил, теперь поехали!
1 Вектор (Vector, Array)
А вы чего ждали?
Вектор (он же одномерный массив) — упорядоченный набор элементов с произвольным доступом по числовому индексу. Что для нас важно в этом определении? Да ничего. Шучу, на самом деле нам важно почти каждое слово:
Доступ к элементам производится по числовому индексу (обычно начиная с 0-го индекса, хотя есть и исключения), обычно доступ к элементу коллекции по индексу записывается как myFavoriteCats[i] или blackKitties[5]. Причем для обозначения этого самого числа — индекса используют букву i.
А когда одной буквы не хватает приплетают сюда j и k.
Итак, далее мы понимаем, что доступ произвольный — значит мы можем обращаться к элементам под индексами 0, 42, 2014 и вобщем-то ожидаем, что операция будет сложности O(1), т.е. константной и независимо от того какой из элементов мы запросим он нам со скоростью света тут же вернется.
Далее — вектор — упорядоченная коллекция, что собственно понятно — у нас есть такие понятия как первый, последний элемент, для каждого конкретно взятого элемента мы также можем назвать предыдущий и следующий.
Релизация
Обычно вектор (как низкоуровневая структура) будет представлять из себя дескриптор, содержащий различную информацию, неотделимую от самой структуры (разумнее всего держать там только размер вектора) и указатель на первый элемент.
Такая реализация позволит за константное время получить доступ к произвольному элементу вектора по его индексу, а также позволит выполнять копирование, конкатенацию и другие простые операции на низком уровне.
И действительно, получить доступ к определенному элементу очень просто — прибавляем к указателю на первый элемент индекс (с некоторыми поправками на размер типа данных) и получаем указатель на нужный элемент! Осталось разыменовать и у нас в переменной нужная кошечка!
Ладно, вектор — классная структура, но и у него есть недостатки (а у кого их нет?!), например нельзя просто так взять и добавить в вектор новый элемент! Особенно втиснуть его в середину. Нельзя также сказать, что кошки с номерами 0, 1 и 4 у нас есть, а с номерами 2 и 3 — нет (раньше они были, но оказалось, что это собаки).
Можно представить себе вектор, как книжную полку с отделениями, в каждом из которых помещается ровно одна книга. Чтобы засунуть новый роман Донцовой между 10-ым и 11-ым томом Большой Совецкой Энциклопедии нужно сильно постараться и переложить все тома с 11-го по 65-ый тома (можно схитрить и поставить 11-ый том в конец, но я вам этого не говорил, да и мы в таком случае потеряем упорядоченность).
В моей памяти все именно так
Применение
В нашем случае вектор бы идеально подошел для топ-10 самых милых котят, т.к. добавлять и удалять элементы не нужно (только изменять), пропусков между 1-ым и 5-ым местом быть не должно, да и удобно обращаться по номеру.
Ладно. В любом случае вектор классный, мы просто посмотрим какие есть еще коллекции.
2 Список (List)
Первый том
Ух! Список задач на сегодня, список покупок в магазине. Список гостей на свадьбу… Так. Ближе к делу.
Мы уже знаем, что элементы вектора лежат акуратненько друг за другом, красиво и ровно. Это дает нам как преимущества так и недостатки.
Список в этом плане полностью противоположная вещь — его элементы могут быть разбросаны по памяти как угодно! Из-за этого мы теряем возможность быстро получить элемент по индексу, а также не можем быстро скопировать весь список, но получаем довольно приятную штуку — мы можем вставлять элементы за константное время в любое место! По слухам удаляются элементы из списка тоже за O(1).
Реализация
Хм. А как с формальным определением?
Список — упорядоченный набор элементов, для каждого из которых хранится указатель на следующий (или для двусвязного списка и на следующий и на предыдущий) элементы списка.
Для последнего элемента списка мы храним нулевой указатель (на диаграммах я буду использовать указатель на нулевую кошку (Null Cat), не пугайтесь).
Внимание! В каноничной реализации списка, для того, чтобы получить размер списка, необходимо обойти весь список — дойдя до нулевого указателя (линейное время — сложность O(n)) и хотя в некоторых реализациях размер кешируется в дескрипторе списка (или в первом элементе), не стоит на это полагаться.
Если бы я мог, я бы один элемент списка разместил на северном полюсе, а другой где-нибудь в окресностях Бетельгейзе
Применение
Список бы подошел для (внимание!) списка бездомных котят, отсортированных по возрасту (по возрастанию). Нам как-раз нужно часто добавлять и удалять элементы из списка (вы не подумайте ничего такого — котят забирают), да и чаще понадобятся первые элементы списка — я бы взял себе маленького пушистого котенка, а не 8-ми-летнего манула.
Ладно. Списки это вроде простая структура. Что есть еще?
3 Множество (Set)
Это Сет
Похожее понятие есть в математике, а точнее в теории множеств. Множество отличается и от вектора и от списка, хотя их реализация может быть похожа.
Множество — неупорядоченный набор элементов, без повторов. Ух. И все? Ни тебе произвольного доступа, ничего! Зачем такое нужно?
Как мы знаем в векторе можно быстро получить элемент по индексу, в списке можно быстро добавить или удалить элемент, а что с множеством?
В множестве можно быстро проверить, есть какой-либо элемент внутри, или его нет. Скажем если бы я хотел узнать, находится ли конкретная кошка в моем списке любимых, то и для списка и для вектора мне пришлось бы перебрать (в худжем случае) все элементы!
Реализация
В множестве, т.к. оно неупорядочено можно сортировать элементы при добавлении и в случае чего устроить бинарный поиск. Хм. Вот ведь парадокс, коллекция неупорядоченная, а внутри все будет по-порядку. Тут важно понять, что если вы добавите новый элемент в множество, не факт, что он пойдет в конец.
На самом деле, работая с множеством вообще нельзя полагаться на какой-либо порядок элементов, он может быть любым — именно поэтому множество и неупорядоченная коллекция.
Стоит отметить, что множество может быть реализовано множеством различных способов, например можно использовать хеширование, для еще более быстрого поиска элементов, поэтому подробно реализацию я рассматривать не буду. Скажу лишь, что можно схитрить и использовать наши знания по спискам.
Вообще есть еще упорядоченные множества, множества с повторами (мультимножество), и вероятно должно быть упорядоченное мультимножество.
Теория множеств дается проще, если брать множество котят
Применение
Множество идеально подойдет для списка любимых котят, потому что их множество. Ха! Шучу.
Но оно действительно подойдет, потому-что такую коллекцию не нужно сортировать (упорядоченность не важна) и мы легко сможем проверить, находится ли какой-нибудь конкретный кот в этом множестве (скажем у меня 100 котят и любимых я кормлю креветками).
Ну ладно. Множества тоже хороши, но неужели есть что-то еще?
4 Словарь (Associative Array, Map, Dictionary)
Признайтесь, это лучше, чем просто словарь
Словарь (он же ассоциативный массив) — это тот-же вектор, но с небольшими отличиями. В качестве индекса (который в словаре будет называться ключ) могут выступать не только числа, но и любые другие типы данных (даже другие коллекции!). Также допустимы пропуски, если мы все-таки будем использовать в качестве ключа целое число, например у нас может быть элемент связанный с ключем 5, но при этом отсутствовать элемент связанный с ключем 4.
Что все это значит на практике? Всего-лишь, то, что в квадратных скобках для ображения к элементу по “индексу” мы можем указывать произвольный тип, например allMyCats[“Murka”].
Реализация
Невооруженным видно, что можно просто завести массив (или список) пар (Ключ, Значение) и добавить специальную функцию, которая будет пробегать по этому списку и возвращать определенное значение по связанному с ним ключу.
Мы также не можем сказать какая пара первая, какая последняя и что раньше “Murka” или “Borka”, поэтому словарь считается неупорядоченной структурой.
Опять-же с каждым ключем может быть связано лишь одно значение, поэтому для приведенного примера с именами кошек словарь в чистом виде подходит слабо.
Реализация, как и в случае со множеством, может быть совершенно различной, можно упорядочить пары по ключу и использовать для получения элемента бинарный поиск (в таком случае элементы должны быть упорядочеваемыми). Опять-же можно реализовать словарь с помощью хеширования ключа, что довольно часто используется со строками.
Применение
Самый правдоподобный и грамотный способ — использовать словарь вместе со списком, где ключем словаря будет строка — имя кошки, а значением — список кошек с таким именем. Это позволит быстро найти всех кошек по имени Мурка и выбрать из них ту, которая в данный момент нужна.
Примерно так выглядит в памяти std::map >
И у меня для вас новость — типы коллекций закончились. Ну все. Вообще больше нет. Совсем.
5 Стек (Stack)
Еще один кот и будет Stack Overflow
Ха! Я вас обманул (всмысле пошутил)! Есть еще пара структур данных, которые представляют коллекции.
Итак стек — коллекция с необычным доступом, точнее с необычными правилами относительно того, как могут быть добавлены и удалены элементы.
Все просто — добавляемый элемент, называемый “последним”, первый выбывает из из стека.
Стек очень нужен и полезен в программировании. Например с помощью стека осуществляется вложенный вызов процедур — в стек сохраняются адрес возврата и аргументы вызванной функции.
Реализация
В высокоуровневой реализации ничего особенно интересного нет — указатель на список и элементы добавляются в начало этого списка, и удаляются с него-же.
В низкоуровневой реализации (точнее то, как он реализован в современных архитектурах) есть интересные моменты.
Стек там является небольшим зарезервированным участком памяти и совместно с ним хранится два указателя — на начало стека (где лежит первый доавленный элемент) и конец стека — где лежит последний добавленный.
Если в стек поместить слишком много данных программа завершится со всем знакомой ошибкой — Stack Overflow, это значит, что указатель на конец стека превысил верхний допустимый предел.
Также может случиться обратная ситуация (Stack Underflow), если попытаться забрать из стека больше чем в нем есть, но в высокоуровневых языках она не встречается (понятно почему — нам не дают напрямую работать со стеком).
Если кому интересно как это все работает — изучение ассемблера для какой-нибудь популярной архитектуры, вроде i386, может вам помочь.
Применение
Можно было-бы описать в этом месте стек из бедных котят высотой с гору, но на самом деле в высокоуровневых языках стек редко необходим, часто хватает рекурсии, которая использует стек неявно. Я не стал прикладывать надуманный пример (и не смог придумать нормальный, простите), поэтому переходим к следующему пункту.
Разное
На самом деле есть еще куча коллекций, таких как очередь, двусторонняя очередь (дек), двусвязанный список, кольцевое множество, очереди с приоритетом.
Есть деревья (да их целый лес!) и графы.
Есть вероятностные структуры данных, такие как вероятностное множество и список с пропусками.
Я очень хочу про все это написать, но времени и места на хабре не всегда мало.
Однако есть множество (или вектор) вещей, относящихся к теме, которые я хотел бы упомянуть хоть вскользь, да просит меня любопытный читатель и пойдет читать умную книгу.
Строки
В первую очередь то, как реализованы строки в некоторых языках может показаться странным. Самое простое и эффективное решение это наверное решение C — строка это набор символов, с нулевым символом в конце, что позволяет обходиться без дескриптора.
В C++ std::string уже больше походит на вектор.
Ну а в старом паскале дескриптор (точнее всего-лишь длина) хранится в нулевом элементе массива.
В Haskell String — это список символов ([Char]), из чего вытекает, что получение длины строки имеет сложность O(n). Зато их очень удобно оббегать рекурсивно.
В общем случае, строка — это упорядоченный набор символов и не более. Какой именно тип коллекции будет использован — не важно (ну я бы не советовал использовать множество, ха!).
Очередь (Queue)
Очередь очень похожа на стек и в тоже время является его противоположностью — первым мы получим обратно не тот элемент, что мы добавили последним, а тот, что “стоит в очереди” дольше всех. Очередь очень удобная структура, но несмотря, на то, что принцип ее работы схож со стеком, в эффективной реализации есть небольшое отличие.
Для стека мы могли схитрить и выделить приемлемый по размеру участок памяти, в случае чего его расширяя, потому-что стек то уменьшается, то увеличивается, т.к. элементы и добавляются и удаляются “с одного конца”. Если же мы представим работу очереди, то она будет “ползти в памяти” — начало будет постоянно сдвигаться вверх, поэтому трюк, который применим для стека, будет работать хуже и тут уже намного лучше будет использовать двусвязный список (и не забудьте хранить указатели на первый и последний элементы).
Еще можете попробовать реализвать очередь на двух стеках, но это тоже менее эффективно.
Также есть дек (двусторонняя очередь — deque). В ней можно добавлять элементы как в конец, так и в начало. И забирать их тоже и с конца и с начала.
Заключение
Ух. Я начинаю повторяться
Я совсем не упомянул, про комбинирование различных коллекций, благодаря которым образуются матрицы, таблицы. Также я не затронул деревья, кольцевое множество, почти ничего не написал про очереди, очень мало информации по хешированию (я таки отделался парой слов от этой темы) и другим методам оптимизации.
Однако я думаю статья исполнит свою роль — просто и понятно изложит основы структур данных для читателей разной степени подготовленности. И я буду рад продолжить и осветить множество (или очередь, ха!) других тем в таком-же ключе.
Спасибо тем, кто смог дочитать аж до этих строк (как они это выдержали?).
Организация словаря данных в предметно-ориентированных программных оболочках.
«Словарь данных представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ. »
Г.Н. Калянов
Создание программных комплексов в современном мире информационных технологий требует все большего участия не программирующих пользователей, которые хорошо знают предметную область. Для этого необходим определенный инструментарий, а также описание данных системы, понятное и доступное не только для системных аналитиков и программистов, но и для пользователей. Один из вариантов решения этого вопроса предлагается в данной статье.
Предметно-ориентированная программная оболочка
При проектировании системы необходимо учитывать факторы, связанные с особенностями ее функционирования в конкретной прикладной среде, такие, как класс задач, для которого предназначается система, квалификация и уровень подготовки пользователя, потенциальные возможности системы, адаптация к другим предметным областям, перспективы развития данной предметной области, среды функционирования системы, вопросы ее коммерческого использования. Эти факторы, наряду с возможностями заказчика в финансировании разработки, в обеспечении техникой, инструментальным программным обеспечением, с возможностями программистского коллектива, определяют выбор средств разработки (языка программирования, СУБД).
Разумно предположить, что в процессе разработки приложений будут участвовать как пользователи, так и программисты. Ввиду того, что не все задачи можно решить методом раскрутки на уровне пользователя, система должна предусматривать возможность расширения и на уровне программиста (разработчика).
Уточним понятие расширяемости. В нашем случае это означает, что система имеет ядро, которое решает прикладные базовые задачи в математической и специальной постановке и способно включать новые функции и приложения. Способ (язык) расширения предполагает непосредственно участие пользователя путем формулировки им прикладной задачи. Кроме того, система предполагает расширение ядра на уровне программиста для того, чтобы реализовать достаточно сложные алгоритмы обработки данных. Система предъявляет относительно невысокие требования к квалификации программиста, что позволит успешно работать с ней в организациях, не способных содержать штат высокооплачиваемых программистов.
Пользователю должна быть представлена информация о функциях и процедурах системы, для возможности профессиональной обработки данных. Таким образом, необходимо создать многоуровневый словарь процедур и функций, в целях упрощения их применения пользователем. Пользователь должен иметь возможность настроить свое рабочее место по своему вкусу, поэтому интерфейс системы должен модифицироваться путем добавления нужных и удаления ненужных ему пунктов иерархического меню, процедур и функций. Понятие «расширяемая» для разработчика программных приложений носит куда более широкий характер. В системе реализуется возможность добавлять собственные библиотеки процедур и функций, программные модули и собственно программные приложения.
Пользователю необходимо свободно общаться с доступными ему данными системы. Это достаточно сложная задача. В данной системе ее предлагается решить с помощью многоуровневых словарей данных, которые в зависимости от уровня доступа пользователя будут наглядно представлять ему доступную структуру данных, тем самым упрощая составление запросов и отчетов. Пользователь может составлять свои таблицы, включая их, по своему желанию, для общего пользования, при этом словарь данных будет пополняться.
Определение элементов данных в словаре
Для того, чтобы словарь данных отвечал задаче проектирования, его элементы должны содержать описание потоков, хранилищ, композиции комплексных данных (расчленяющихся на элементарные), движущихся по потокам, и групповых данных хранилищ, описание деталей отношений между хранилищами.
Но конечного пользователя эти проблемы касаются мало, в частности потому, что он либо не принимает вовсе, либо принимает ограниченное участие в разработке ядра системы. В силу того, что пользователь сложной системы работает лишь с ее частью (подсистемой), его в основном интересуют данные, связанные непосредственно с участком работы, за который он отвечает и который обычно имеет локальный характер. Для привлечения пользователя к разработке в части извлечения из него информации о предметной области необходимо, чтобы словарь предметно-ориентированной программной оболочки был структурирован по автоматизированным рабочим местам пользователя (АРМ) и администратора системы. Но это не исключает существования общего словаря данных, здесь лишь отмечается особенность подхода к проблеме его создания в предметно-ориентированной оболочке.
Перейдем теперь к классификации данных с точки зрения доступа к ним пользователя (администратора) системы. Заметим, что идеология предметно-ориентированной оболочки допускает отсутствие описания (отображения) некоторых данных в словаре системы. В основном это данные, связанные с настройкой и жизнеобеспечением системы, защитой от несанкционированного доступа и т.п. Разработчик приложений в этом случае сможет получить необходимую дополнительную информацию особо.
Исходя из концепции предметно-ориентированной оболочки, словарь должен содержать описание структуры данных, определенной разработчиком (поставляемыми с системой) и определенной пользователем, характерной только для конкретного АРМа. Некоторые элементы пользовательской структуры в силу локальности могут не включаться в общий словарь данных.
Введем некоторые определения и обозначения, которые будут использоваться в дальнейшем изложении, а также примем некоторые ограничения, которые служат для упрощения общепринятой концепции словаря данных. Это необходимо для построения модели словаря данных предметно-ориентированной оболочки.
Хранилищем будем называть файл, предназначенный для хранения данных системы, имеющих стандартный формат таблицы, характеризующийся постоянной структурой. Формат записи: «имя хранилища».
Атрибутом хранилища назовем атрибут таблицы (поле). Формат записи: «имя хранилища».»название поля».
Дугой будем называть направленную связь между двумя хранилищами. Формат записи: «имя хранилища»-«имя хранилища».
Атрибуты, включаемые в словарь, подразделяются на первичные и вторичные.
Под первичными данными будем понимать 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.