Прибыль:
- Способность объяснять концептуальные, логические и физические модели данных и концепции нормализации, а также создавать проекты сущностей и связей при поддержке искусственного интеллекта.
- Возможность составлять словарь данных, бизнес-правила и связи между таблицами с помощью структурированных подсказок и сверять их с реальной системой.
- Способность критически оценивать предложения схем, созданные ИИ, с точки зрения целостности, уникальности и соответствия бизнес-правилам.
Информационная система — это, по сути, структура, которая обеспечивает организацию данных. Моделирование данных — это задача структурированного проектирования фактов бизнеса (клиент, заказ, продукт, счет) и их взаимосвязи друг с другом. Хорошая модель данных — это основа точных отчетов, быстрых запросов и согласованных данных; Плохая модель является источником многих лет непоследовательности и повторяющейся корректирующей работы. В большинстве случаев специалист по MIS не кодирует модель с нуля, а проверяет ее соответствие бизнес-правилам и транслирует модель между бизнес-подразделением и ИТ-отделом.
Моделирование данных происходит на трех уровнях абстракции. Концептуальная модель (англ. Conceptual) — высший уровень: какие основные сущности существуют и как они связаны между собой? «Клиент размещает заказ, заказ включает в себя продукт». Никаких технических подробностей нет. Логическая модель определяет атрибуты (поля), ключи и типы отношений каждой сущности; но он по-прежнему не привязан к конкретной базе данных. Физическая модель (англ. Physical) — это конкретная версия таблиц, типов данных и индексов в конкретной базе данных (например, SQL Server, PostgreSQL). Эти три уровня представляют собой все более подробные версии одной и той же идеи.
Сущностные отношения и ключи
Базовым языком модели данных является модель Entity-Relationship (ER). Сущность можно представить как таблицу: Клиент, Заказ. Атрибут — столбец таблицы: имя, адрес электронной почты, сумма. Отношения — это то, как связаны сущности: у клиента может быть много заказов (отношения «один ко многим»).
Есть две важнейшие ключевые концепции. Первичный ключ — это поле, которое однозначно идентифицирует каждую строку таблицы; например идентификатор клиента. Внешний ключ — это поле в одной таблице, которое указывает на первичный ключ другой таблицы; CustomerID в таблице заказов определяет, какой это заказ клиента. Эти связи обеспечивают ссылочную целостность: заказ не может быть размещен для несуществующего клиента.
Совет: когда ИИ генерирует черновик ER, становится проще явно запросить первичный ключ для каждой таблицы и внешний ключ для каждой связи. Но проверяйте каждый внешний ключ, предложенный моделью, на соответствие фактическому бизнес-правилу: иногда отношения, которые вы считаете «один-ко-многим», на самом деле являются «многими-ко-многим».
Нормализация: предотвращение повторения
Нормализация — это процесс уменьшения избыточности и сохранения целостности путем разделения данных на логические таблицы. Цель состоит в том, чтобы хранить одну и ту же информацию в одном месте. Например, вместо того, чтобы снова и снова вводить адрес клиента в каждой строке заказа, вы сохраняете адрес один раз в таблице «Клиенты» и связываете его с внешним ключом заказа. Таким образом, при изменении адреса вы обновляете его в одном месте; В противном случае сотни заказов будут иметь разные адреса. Это называется аномалией обновления.
Противоположностью нормализации является денормализация: намеренное разрешение некоторого повторения ради скорости отчетности. В бизнес-системах (оперативная база данных) обычно предпочтительна нормализация, а в системах отчетности (хранилище данных) часто предпочтительна денормализация. Так что «нормализация не всегда хороша»; Решение принимается в зависимости от цели.
Словарь данных: общий язык
Словарь данных — это документ, который определяет, что означает каждое поле, его тип, ограничения и бизнес-правила. Что означает поле «статус»? Какие значения он может принимать (Ожидание, Утверждено, Отменено)? Это обязательно? Без этого документа одно и то же поле будет интерпретироваться разными командами по-разному и отчет будет искажен. Словарь данных — это лингва франка организации и один из наиболее ценных результатов деятельности специалистов по информационным информационным системам. ИИ может быстро извлечь исходный вариант словаря данных из существующей структуры таблицы; Но только то подразделение, которое использует эти данные, проверяет истинное деловое значение каждого поля.
Три мини-кейса: в цифрах
Случай 1 — Стоимость повторения. В дистрибьюторской компании адрес клиента хранился отдельно как в таблицах заказов, так и в таблицах счетов. При переезде клиента адрес обновлялся только в одной таблице; 1400 счетов были отправлены на старый адрес и возвращены. Если бы адрес был нормализован в одной таблице, одного обновления было бы достаточно. Проект восстановления стоил 2 недели.
Случай 2 — Неправильный тип отношений. Эксперт MIS в образовательном учреждении признал связь (один-ко-многим) «Студент принадлежит к классу» в модели, сгенерированной ИИ. Однако студенты могли записаться более чем на один факультативный класс; На самом деле связь была «многие-ко-многим», и требовалась промежуточная таблица (запись). Ошибка выявилась на местах, когда ученику не удалось записаться во второй класс. Если бы предложение ИИ было подтверждено, оно было бы уловлено с самого начала.
Случай 3 — Значение словаря данных. Было установлено, что поле «policy_status» в страховой компании 5 разными командами интерпретировали по-разному, поэтому один и тот же KPI давал в отчетах 3 разных результата. Благодаря составлению словаря данных на базе искусственного интеллекта и достижению единообразного соглашения с бизнес-подразделением были устранены несоответствия в отчетах, а время ежемесячных встреч по сверке сократилось на 60%.
Слабая подсказка/Сильная подсказка
Слабая подсказка:
Создайте базу данных электронной коммерции.
Мощная подсказка:
Ваша роль: Вы опытный разработчик моделей данных. СОЗДАЙТЕ ЛОГИЧЕСКУЮ модель данных в соответствии со следующими бизнес-правилами. Правила: - Для каждой сущности: поля, первичный ключ, обязательные поля. - Для каждого отношения: тип (один-ко-многим / многие-ко-многим) и внешний ключ. - Предложите промежуточную таблицу в отношениях «многие ко многим». - Нормализуйте до 3-й нормальной формы; Если вы рекомендуете преднамеренную денормализацию, напишите обоснование.- Отметьте [ТРЕБУЕТСЯ ПОДТВЕРЖДЕНИЕ] любое бизнес-правило, в котором вы не уверены. Бизнес-правила:- Клиент может разместить несколько заказов.- Заказ содержит несколько продуктов; Один товар встречается во многих заказах.- Товары имеют категории.[другие правила...]
Мощная подсказка поясняет уровень модели (логический), правила ключей и отношений, цель нормализации и точки, требующие подтверждения.
Четыре копируемых шаблона
1) Проект словаря данных:
Структура словаря данных следует из определения таблицы. Для каждого поля: имя, тип, является ли оно обязательным, возможные значения, бизнес-значение (метка[ПРЕДИКЦИЯ], если это прогноз). Таблица: [DDL или список полей]
2) Обзор нормализации:
Существует ли риск дублирования данных, аномалии обновления и возможности нормализации в структуре таблицы ниже? Для каждого результата запишите, какую нормальную форму он нарушает, и ваше предложение. Структура: [текст]
3) Черновик ER из бизнес-правила:
Переведите следующие бизнес-правила в сущности, атрибуты и отношения. Укажите тип каждой связи (1-1, 1-N, N-N), а если N-N, предложите промежуточную таблицу. Отмечайте неоднозначные правила. Правила: [текст]
4) Вопросы для проверки типа отношений:
Для каждой связи в приведенной ниже модели данных создайте бизнес-вопрос «да/нет», который будет проверять правильность его типа (например, «Может ли учащийся быть зачисленным более чем в один класс одновременно?»). Модель: [текст]
Сравнительная таблица: уровни моделей
особенность
концептуальный
логичный
физический
Деталь
по крайней мере
средний
большинство
ключ/отношение
Основные активы
Ключи определены
Включая индекс/тип
Зависит от базы данных
нет
нет
Да
целевая аудитория
бизнес-единица
аналитик
Разработчик/администратор базы данных
Вклад ИИ
проект
сильная тяга
Черновик, подтверждение администратора базы данных
Распространенные ошибки
- Думая об отношениях «многие-ко-многим», как об «один-ко-многим». Это наиболее распространенная ошибка моделирования; Если промежуточная таблица забыта, система не сможет сохранить фактическое состояние.
- Собираем все в одну таблицу. Сбор всех полей в одной таблице ради «простоты» приводит к дублированию и аномалиям обновления.
- Не писать словарь данных. Один и тот же KPI дает разные результаты, когда значение полей остается в сознании.
- Слепо доверяя рекомендациям ИИ относительно типов данных и ограничений. Модель может предполагать «достаточно большую» территорию; Бизнес-правило определяет фактические ограничения (например, 11-значный идентификатор TR).
- Абсолютизирующая нормализация. Чрезмерная нормализация на уровне отчетов замедляет выполнение запроса; Цель варьируется в зависимости от контекста.
Внимание: искусственный интеллект может создавать модели, которые выглядят красиво, но нарушают бизнес-правила. Для каждого отношения, предложенного моделью, вопрос «действительно ли это так?» Задайте деловой вопрос. Модель данных — это скелет системы; Перелом скелета впоследствии очень трудно восстановить.
В заключение
Моделирование данных — это процесс структурирования бизнес-фактов с помощью сущностей, атрибутов и отношений, который происходит на концептуальном, логическом и физическом уровнях. Первичные и внешние ключи обеспечивают ссылочную целостность; Нормализация уменьшает повторение, но денормализация также допустима в зависимости от цели. Словарь данных — это общий язык организации. ИИ обеспечивает значительную скорость создания черновиков электронных отчетов, словарей данных и обзоров нормализации; однако типы отношений, типы данных и бизнес-семантика должны быть подтверждены на соответствие фактическому бизнес-правилу. То, что модель выглядит хорошо, не означает, что она правильная.
Задача приложения
Рассмотрим «систему абонемента библиотеки»: члены, книги, записи о выдаче. (1) Создайте логический черновик модели, созданный с помощью мощной подсказки. (2) Проверьте тип каждого отношения, который предлагает модель (в частности, «может ли у участника иметь более одного экземпляра одной и той же книги?») с помощью делового вопроса. (3) Найдите хотя бы одно отношение «многие ко многим» и определите промежуточную таблицу. (4) Напишите строки словаря данных как минимум для 4 полей (имя, тип, обязательное значение, деловое значение). (5) Выделите ограничение, которому могла соответствовать модель, и объясните, как вы будете его проверять.
контрольный список
- [ ] Определяется первичный ключ каждой таблицы.
- [ ] Я проверил тип каждой связи с деловым вопросом.
- [ ] Я определил промежуточную таблицу для отношений «многие ко многим».
- [ ] Я нормализовал или обосновал денормализацию повторяющихся данных.
- [ ] Я написал строку словаря данных для критических полей.
- [ ] Я подтвердил предложения ИИ по типу данных/ограничениям на соответствие бизнес-правилу.