Л лр№ 24абораторный практикум
Формирование знаний и умений по разработке словаря данных (СД) для проектирования базы данных (БД) приложения.
Определение состава данных из объекта автоматизации (ОА), которые должны храниться в БД создаваемого приложения, и представление их в виде СД.
Изучить структуру и назначение компонентов информационного обеспечения приложения (см.п.2).
Разработать локальный словарь данных для каждого выходного документа приложения (см.п.3).
Объединить локальные словари данных в общий СД БД (см. п.3).
Поиск и изучение структуры и содержания входных документов для ОА (см. каталог «Примеры документов» в каталоге Лаб 02).
Разработать макеты для входных документов приложения или использовать готовые бланки.
Определить источники данных для всех элементов данных из СД БД (см.п.3).
Решить (при необходимости) проблемы, возникшие при построении СД БД.
Документировать результаты выполнения лабораторной работы.
ИСХОДНЫЕ ДАННЫЕ ДЛЯ ЛАБОРАТОРНОЙ РАБОТЫ:
Результаты выполнения лабораторной работы «Постановка задачи на создание приложения»:
описание функций приложения;
описание данных приложения.
макеты выходных документов приложения.
Бланки готовых входных документов (см. каталог «Примеры документов» в каталоге Лаб 02).
РЕЗУЛЬТАТ ВЫПОЛНЕНИЯ РАБОТЫ:
Отчет по лабораторной работе должен содержать следующие разделы:
Макеты выходных документов (рисунки или готовые бланки документов).
Общий словарь данных БД (таблица).
Локальные словари данных (таблица для каждого выходного документа и одна для выходных показателей).
В случае возникновения проблем при построении СД возможно внесение изменений в макеты выходных документов приложения (результаты лабораторной работы 1).
2. Общие понятия и определения
Структура информационного обеспечения (ИО) приложения. Общая структура ИО приложения изображена на рис.2.1. Основными компонентами ИО являются входные и выходные данные (документы, показатели) и БД приложения.
По приложения
Информационное обеспечение приложения
Рисунок 2.1 – Общая структура ИО приложения
К базе данных (БД) приложения предъявляется следующие требования:
БД должна содержать совокупность данных достаточную для формирования всех выходных данных приложения.
Данные, содержащиеся в БД, должны находиться в актуальном состоянии, т.е. вводится, редактироваться и т.д., и соответствовать текущему состоянию объекта автоматизации.
Для проектирования структуры БД первоначально необходимо определить перечень данных, который должен храниться в БД. Этот процесс называется построение словаря данных (СД) для БД.
Словарь данных — это описание совокупности данных, перечень которых необходим и достаточен для реализации функций создаваемого приложения. В СД не должны содержаться данных, которые вводятся, но не используются. Для описания СД будем использовать табличный способ описания. Таблица состоит из строк. Отдельная строка описывает одно элементарное данное (ЭД) из ОА. В общем случае, ЭД может быть массивом данных. Примерный макет таблицы для описания СД приведен ниже (см. табл.2.1).
Name already in use
PiRIS / articles / 5_1_1_1_data_dictionary.md
- Go to file T
- Go to line L
- Copy path
- Copy permalink
- Open with Desktop
- View raw
- Copy raw contents Copy raw contents
Copy raw contents
Copy raw contents
Недостатком ER-диаграмм является их недостаточная детализация данных, поэтому они часто дополняются более подробным описанием, которые собираются в словари данных.
Словарь данных представляет собой определенным образом организованный список всех элементов данных системы с их точными определениями, что дает возможность различным категориям пользователей (от системного аналитика до программиста) иметь общее понимание всех входных и выходных потоков и компонентов хранилищ.
Словарь данных содержит описание сущностей (таблиц), включающее в себя определение атрибутов, а также дополнительные сведения, например, единицы измерения и диапазоны изменения атрибутов, цель определения такого объекта, сведения о его разработчике и времени создания и т.д.
В каталоге docs этого репозитория лежит шаблон словаря данных.
Возьмем описание предметной области одного из предыдущих демо-экзаменов и заполним словарь данных:
Подсистема работы с клиентами
Подсистема работы с клиентами включает в себя возможность добавления новых клиентов, отслеживание их посещений, а также контроль их бонусной программы.
Запись о клиенте содержит следующие данные: фамилию, имя, отчество, дату рождения, телефон, электронную почту, пол, дату первого посещения (регистрации), фотографию клиента. В связи с тем что у компании большое количество клиентов, то их удобно собирать с помощью определенных ярлыков (тегов), которые позволят очень удобно помечать клиентов (например, новый, постоянный, проблемный, горячий). Теги помимо названия должны иметь еще и определенный цвет.
Посещения клиента в рамках оказания услуг должны обязательно фиксироваться в БД.
Для начала, размеремся какие параметры заносятся в словарь данных
Key — признак, что поле является ключём. Для разных типов ключей приняты определенные обозначения:
- PK — первичный ключ (primary key)
- FK — внешний ключ (foreign key)
- IDX — индекс (альтернативный ключ)
Не нашёл как описывать составные ключи
Field Name — название атрибута (латиницей). Ещё раз напоминаю, что мы везде используем CamelCase
Data Type/Field Size — тип данных / размерность поля
Required? — вписывается «Y», если поле обязательное (для не обязательных ничего не пишем)
Notes — примечание. Заполняется, если назначение поля не самоочевидно из названия или для поля есть домен
Пример заполнения элемента словаря данных
Во-первых, Выделим из описания предметной области сущности:
- Клиент
- Пол клиента
- Теги клиента
- Посещения клиента
Заполним элемент словаря данных на примере таблицы Клиент
Шесть картинок, как создать словарь
Словарь — это абстрактный тип данных, который связывает ключи со значениями. Его ещё называют ассоциативный массив, карта, таблица символов, коллекция. Будет две статьи на эту тему, где мы покажем шесть картинок / способов реализации словаря, которые отличаются друг от друга по времени работы и по требованию к памяти.
Двоичное дерево поиска
Дом для кота, Интерфейс для словаря
Начнём созидание словаря с формулировки методов для работы с ним. Минимальный набор таких методов: put — добавить, get — получить.
По хорошему, мы должны создать обобщённый интерфейс с возможностью указать любой тип данных как для ключа, так и для значения. Однако, в рамках этой работы мы будем для удобства использовать string для ключей, int для значений. Ещё в словаре могут быть методы для удаления ключей, для итерации по всем записям, получение количества элементов и много других важных и приятных мелочей, которые мы опустим.
Пример кода на языке Java
Картинка первая. Линейный массив.
Самый простой способ для хранения пар «ключ, значение» — это создание класса или структуры Node (узел) и декларация линейного массива сих пар.
Для поиска узла по ключу необходимо просканировать весь массив от начала до конца и в каждом узле проверять, не совпало ли значение. Если совпало — вернуть найденное значение, если сканирование завершилось, а значение так и не было найдено — рапортуем, что не найдено. На это нужно N операций.
Для добавления новой пары достаточно в конец массива вписать новый узел, это быстро, всего 1 операция. Однако, прежде чем добавить новый узел, мы должны убедиться, что в словаре нет узла с точно таким же значением ключа, для этого необходимо вызвать метод поиска. Если такой ключ есть — мы записываем новое значение на место старого.
Сколько памяти выделять для словаря? Какого размера массив необходимо декларировать для эффективной работы? Если размер массива будет совпадать с количеством элементов, то при каждом добавлении пары необходимо пересоздавать массив увеличенного размера и заниматься копированием значений из старого массива в новый, а это, на минуточку, N действий для каждой операции добавления элемента.
Чтобы избежать тьмы лишних действий, можно выделять массив удвоенного размера, тогда процесс пересоздания массива добавит к сложности алгоритма лишь Log N операций, однако размер требуемой памяти удвоится.
Сложность поиска: N операций = O(N).
Сложность вставки: N (поиск) + Log N (пересоздание) + 1 (вставка) = O(N).
Требование к памяти: N (словарь) + N (резерв) = O(N).
Вывод: простой, но медленный способ, двойной расход памяти
Исходный код Storage1_Array можно посмотреть и запустить здесь.
Картинка вторая. Односвязный список.
Есть идеи по экономии памяти, но чтобы при этом не нужно было тратиться на дополнительные операции по пересозданию массива и копированию элементов? Ответ лежит на поверхности: односвязный список! Это динамическая структура, которая занимает ровно столько место, сколько в ней элементов и позволяет легко добавлять новые сущности.
Как видим, в класс узла добавилось ещё одно поле next — указатель на следующий элемент списка (между нами говоря, накладные расходы на необходимость хранить этот указатель могут свести на нет то, ради чего мы, собственно, и).
Сложность поиска узла по ключу не изменилась — нам вновь необходимо сканировать весь список от начала до конца, прыгая по кочкам списка.
Сложность добавления элемента значительно ускорился — нет дополнительных расходов на пересоздание массива, а новые пары удобнее всего добавлять в начало списка. Обратите внимание, что на рисунке порядок расположения пар реверсивен: кот был первым, а стал последним.
Сложность поиска: N операций = O(N).
Сложность вставки: N (поиск) + 1 (вставка) = O(N).
Требование к памяти: N (словарь) = O(N).
Вывод: простой, но медленный способ, эффективен по памяти.
Исходный код Storage2_LinkedList можно посмотреть и запустить здесь.
А можно ли как-то ускорить процесс поиска ключей? Линейное время, это слишком медленно и применимо лишь на малых размерах словаря. Можно.
Картина третья. Отсортированный список.
В книжных словарях слова расположены по алфавиту, что позволяет искать их значительно быстрее, за логарифмическое время. Например, для поиска ключа в отсортированном списке из 1000 записей достаточно сделать всего десять сравнений, потому как 2^10 = 1024.
Давайте и мы попробуем располагать ключи в алфавитном порядке.
Теперь для поиска ключа можно применить бинарный поиск: смотрим, какой элемент посередине списка находится и рекурсивно продолжаем поиск либо в первой половине, либо во второй. Время поиска O(Log N).
Для добавления новой пары в словарь нужно сначала найти индекс в массиве, куда следует вставить пару, чтобы ключи располагались в алфавитном порядке, на это нужно Log N операций. Затем нужно сдвинуть все элементы на одну позицию вперёд и в освободившееся место разместить новую пару. Хотел бы обратить внимание, что сдвигать элементы нужно с хвоста поезда.
На сдвиг элементов может потребоваться до N действий. Возможны дополнительные операции на пересоздание и копирование массива в размере Log N.
Сложность поиска: Log N операций = O(Log N).
Сложность вставки: Log N (поиск) + Log N (пересоздание) + N (сдвиг) + 1 (вставка) = O(N).
Требование к памяти: N (словарь) + N (резерв) = O(N).
Вывод: логарифмический поиск, линейное добавление, двойной расход памяти.
Исходный код Storage3_SortedArray можно посмотреть и запустить здесь.
Кстати, а можно ли уменьшить расходы по памяти, используя для хранения пар односвязный отсортированный список? Увы, нельзя. Потому как мы можем только скользить по односвязному списку, без возможности перехода к любому элементу по индексу. А отличительная черта обычного массива — это моментальный доступ к любому элементу по его индексу, что и используется при двоичном поиске ключа в отсортированном массиве.
Впрочем, мы можем отказаться от излишних копирований и сдвигов элементов, если для хранения словаря воспользуемся двоичным деревом поиска.
Но об этом в следующей статье, а также на бесплатном уроке, который пройдет уже 20 октября.
Building a SQL Server data dictionary
In this article, Edward Pollack explains the benefits of a SQL Server data dictionary and how to build one.
A data dictionary is a documentation tool that provides metadata, metrics, or details about a database and the data within it. Documenting data is critical to maintaining, sharing, and using it, and therefore this is a tool that can save time, improve code quality, and improve communication.
In this article, we will explore the process of designing, architecting, and implementing a data dictionary. But wait, this is only the beginning! A good data dictionary does not need to be entirely manually maintained. Many aspects of metadata, locating new data elements, and reporting/alerting on unusual changes can be built into a data dictionary. Automation allows a majority of the documentation to maintain itself, allowing it to be more accurate, require less manual updating, and be easier to use.
What is a data dictionary?
A data dictionary can be seen as a repository for information about a database. There are no industry standards that go into a data dictionary. It may be as simple as a list of tables with basic descriptions. Alternatively, it can be an extensive list of properties outlining precisely how data is structured, maintained, and used.
Software applications can be purchased and used to maintain a data dictionary. These applications can inspect a database and create metadata lists using internal database properties or their own proprietary data structures. Third-party applications are convenient and easy to use but may be limited in scope and are typically not free; however, they may have features that would be difficult or impossible for an individual to create.
For this discussion, a data dictionary will be built from the ground up using T-SQL. While this work will be done in SQL Server, a similar process could be written in other database systems to perform the same tasks. The benefits of building a data dictionary from scratch are:
- No monetary costs/licensing/contracts
- No need to share data with third-party organizations (if applicable)
- Can customize as much (or as little) as wanted.
- Can use this data in other applications via APIs or reporting processes
No process is without downsides. Building a data dictionary from scratch (like anything homegrown) entails:
- Time
- Resources
- Maintenance
The larger the project, the more work this will be, and it is quite likely that an exceptionally complex documentation project would benefit from a careful analysis of different approaches to ensure the best one is chosen. Similarly, if the documentation need is modest, then build-your-own will tend to be the most efficient solution.
Generally speaking, these costs will be lower than the time needed to maintain documentation via less organized means. A Word doc or Google Sheet do not represent adequate data documentation. Similarly, having no documentation is the worst-case scenario, and any organized data dictionary would be beneficial when compared to having nothing.
An additional note on lock-in: If a homegrown data dictionary outgrows its environment, then it is always possible to migrate data into another solution (homegrown or 3 rd party).
Why a data dictionary? Why not system views?
All database systems include a variety of internal tables and views that allow developers to view object names, data types, and other built-in properties. These views are exceptionally useful for operations and the automation of administrative functions (such as index maintenance, backups, ETL, etc.).
The following query retrieves all columns and some related metadata within a database using system views. You can download all code for this article here.
The results are as follows:
These results are easy for an administrator or developer to consume but have limited use beyond that scope. In addition, there is no human-readable documentation included. Any data dictionary needs to be easily consumable by people in different roles within an organization.
How about extended properties?
Extended properties can provide a way to add metadata inline to objects, like this:
Once added, they can be viewed in the SQL Server Management Studio GUI: 
Similarly, they can be queried via T-SQL:
The results of that query are as follows:
Extended properties are a convenient, built-in way to add descriptions to objects. Their documentation ability is limited, though, as you are restricted to a name and value. Using them in practice is similar to managing system views and requires database access or a report that accesses the objects for you.
For very simple and limited details, extended properties provide an easy and effective solution. For anything more extensive, though, they are inadequate and do not constitute the level of depth required of documentation for most organizations.
Building a data dictionary
Building a customized data dictionary is labor-intensive, but the most time-consuming steps are not designing, architecting, and implementing code but collecting details needed to realize business meaning within this metadata.
The first step in this process is to build a table to store data. For this work, the result will be simplified to a single table and not normalized. The reasons for this are to keep the schema simple and easy to consume and to acknowledge that the table will not be large, and therefore complex dimensions are unlikely to be valuable.
What goes into this table? Anything really. If what is needed is not here, add it. If some columns are unnecessary, then remove them:
Each column provides a basic detail about a column that lives in a database somewhere:
data_element_id: A numeric primary key for the table. It can be used to identify a row. The natural key of database_server, database_name, schema_name, table_name, and column_name can also be used as a primary or alternate key.
data_element_name: A informal name for the column. For database objects that are already well named, this may require little effort, but for any that are poorly named, a familiar/casual name can provide great value to anyone using this data.
data_element_type: If OLAP data, then there is value in documenting whether a column represents a fact or dimension. This detail may or not be necessary, depending on the data that is being documented.
data_type: The data type as defined in SQL Server.
data_purpose: The overall purpose of the application that consumes this data. This is something generic to allow a user to understand the over-arching reason that this data exists. This will typically be the same for many tables (or an entire database) that share a common use-case.
entity_purpose: The purpose for this specific table. This will usually be the same for all columns in the table.
database_server, database_name, schema_name, table_name, column_name: These are all taken straight from SQL Server and together describe the unique location and name for the data element.
original_data_source: This is where you can document a data element’s origin if it is not the same as it’s current location. This column is useful for copied, moved, or archived data via ETL or reporting/analytics processes as it can document its original source before it was moved.
notes: A free-form text field for any details about the column, its usage, and its meaning. While anything can go here, it’s worthwhile to maintain a consistent strategy for adding notes so that users of this data know what to expect as they are reading this.
foreign_key_to: If the column references a column in another table, it can be documented here. If a database is relational, then this column can be populated from sys.foreign_keys and sys.foreign_key_columns . If the database is not relational, this will involve some manual or semi-autonomous work to maintain.
row_count: The row count of the table. This value can be collected quickly and easily from sys.dm_db_partition_stats and allows the consumer of this data to understand its size as a table with 1,000 rows will be used differently than a table with 1 billion rows.
data_start_time and data_end_time: If the data has a defined start/end time, it can be provided here. A column for the data retention policy could similarly replace this and provide functionality for columns that undergo regular cleanup or archiving. Essentially, these columns (or something similar) provide detail on when data began to be populated and when (or if) it ends. For a table where columns are added over time but not backfilled, this can be exceptionally useful.
create_time and last_update_time: This documents when a column was added to the data dictionary and when it was last updated.
is_deleted: If data element details will be retained for posterity for deleted columns, then flagging them as deleted is necessary. Additional information could be provided as well, such as the time of deletion and reason.
is_nullable: If data element is a NULL able column, then this will be set to 1.
Once a table is defined, metadata can be inserted. In its most basic usage, data can be inserted manually. This effort would make the table about as efficient as a fully-manual wiki, document, or version-controlled source-code system. For testing, populating data like this is adequate, but long-term, automation is needed.