Обсуждение:Модель данных

Материал из Википедии — свободной энциклопедии
Перейти к навигации Перейти к поиску

Модели данных (незавершенный набросок статьи):[править код]

Термин "модель данных" ввел в обращение, по-видимому, Эдгар Кодд. Во всяком случае, Кристофер Дейт в работе "Анализ вклада Кодда в Великий Спор" утверждает, что "Кодд был первым человеком, который попытался дать формальное определение не только реляционной модели, но также и сетевой модели данных". Интересно, что в своих основополагающих работах ни сам Кодд, ни его соперник по Великому Спору (состоявшемуся в 1974 году под эгидой ACM), автор сетевой модели Чарльз Бахман, не использовали термин "data model". Более того, представления Кодда о том, что такое модель данных, и даже реляционная модель, неоднократно менялись в течение всей жизни, и до сих пор это понятие не имеет однозначного толкования.

Выделить какие-либо существенные признаки, характеризующие ту или иную модель данных весьма непросто - даже при описании родственных иерархической и сетевой моделей терминология резко отличается. Понятия записи, набора, сегмента, узла, кортежа, объекта, типа и другие иногда используются как синонимы, но нередко даже один и тот же термин используется в разных смыслах. Кроме того, можно ли всерьез говорить, например, об объектной модели данных, если до сих пор отсутствует точное определение термина "объект"? Лучше других формализована реляционная модель данных, однако большинство(!) СУБД, которые принято называть реляционными, в реальности ее не поддерживают.

Итак, что же такое модель данных? В статье "Модели данных в управлении базами данных" Кодд определяет модель данных как комбинацию трех компонентов: 1. Коллекции типов объектов данных, образующих базовые строительные блоки для любой базы данных, соответствующей модели; 2. Коллекции общих правил целостности, ограничивающих набор экземпляров тех типов объектов; 3. Коллекции операций, применимых к таким экземплярам объектов.

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

К сожалению, такое определение мало что говорит человеку, слабо знакомому с предметом. В литературе, статьях и в обиходной речи иногда встречается использование термина "модель данных" в смысле "схема базы данных" (модель базы данных). Такое использование является неверным, на что указывают многие авторитетные специалисты, в том числе Кристофер Дейт: "Модель данных есть теория, или средство моделирования, в то время как модель базы данных (схема базы данных) есть результат моделирования. Соотношение между этими понятиями аналогично соотношению между языком программирования и конкретной программой на этом языке".

Таким образом, сам того не желая, Дейт дал совершенно блестящее, понятное даже ребенку, определение модели данных: это именно язык! Или, точнее, семество языков: ЯОД - язык определения данных (Data Definition Language, DDL), ЯМД - язык манипуляции данными (Data Manipulation Lanfuage, DML) и... тут же выясняется, что не хватает еще одного языка - для третьего аспекта понятия "модель данных": языка описания правил или ограничений целостности. Можно с достаточной уверенностью предсказать появление таких языков в будущем. Косвенным свидетельством в пользу точности определения Дейта является факт существования так называемых "SQL-серверов" - концепции баз данных, отличающейся от реляционной модели во многих деталях, и содержащих слово "язык" уже в названии (Structured Query Language).

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

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

Кроме атомарных, существуют также элементы данных, представляющие собой группы полей, называемые разными авторами "сегментами", "наборами" и другими терминами. В действительности же существует лишь два типа групп однородных элементов: массив (array) - множество элементов заданного размера, и строка (string) - множество, размер которого явно не задается, а определяется по заранее специфицированному значению элемента строки (терминатор, NULL). Существуют также группы разнородных элементов, отличающиеся главным образом названием: это struct (языки программирования), class (объектная парадигма), tuple (кортеж, реляционная модель данных), node (узел, теория графов). В самом деле, понятие class отличается от struct лишь возможностью заполнять конкретными значениями поля структуры при ее описании ("в нагрузку", разумеется, получаем конструкторы с десктрукторами). Если мысленно разрешить узлы графа считать не только атомарными элементами, но и структурами, а понятие tuple также сделать полностью эквивалентным понятию struct (т.е. элементом группы может быть группа), мы получим возможность реально сравнивать любые модели данных (а заодно "совершенно бесплатно" получим объектную модель данных на месте реляционной - правда, ценой уничтожения реляционной алгебры).

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

Структурный аспект реляционной модели: данные в базе данных представляют собой набор отношений. Вот оно, главное противоречие: первичный элемент есть таблица, т.е. группа! Если же отношение определить как массив кортежей, а сам кортеж, как совокупность полей, тогда действительно становится возможным реальное сравнение с единичными элементами сетевой модели: узлами и ребрами. Однако мы сразу же увидим и набор жестких ограничений на сложность данных в отношениях: возможность группировки только однородных элементов, возможность представления кортежа лишь одноуровневым деревом и, самое неприятное - невозможность обратиться к элементу по идентификатору, неизбежным следствием чего является концепция "ключа". Ради чего? Ради упрощения формального аппарата алгебры отношений и реляционного исчисления для обработки данных. Причем понятие идентификатора, "жульническим" образом изъятое из модели данных, принципиально не может быть убрано также из РСУБД - ведь даже для тривиального чтения значения ключа нужно получить доступ к кортежу каким-то иным способом.

Если же, наоборот, привести терминологию сетевой модели к реляционной (первичный элемент есть множество), мы также получим возможность корректного сравнения двух моделей данных. В качестве ключа проще всего использовать существующую и в реляционной модели концепцию "суррогатного ключа" - скажем, регистрационного номера элемента данных в БД (как было показано выше, полностью избавиться от понятия идентификатора невозможно - можно лишь "сделать вид", что его не существует при групповой обработке данных). Кроме того, нам потребуется явно прописать ссылки на соответствующие метаданные - в реляционной модели механизм доступа к метаданным (именам таблиц, атрибутов, типам данных столбцов) не специфицирован вообще никак. В этом случае сетевая модель будет иметь более высокий уровень сложности элементов данных: возможны группы узлов, в т.ч. не ограниченных требованием первой нормальной формы, а также группы ребер (каналы) и даже субграфов (элементов, размещенных сразу в нескольких узлах графа). Сама специфика сетевой модели (хранение данных вне таблиц) автоматически обеспечивает возможность образования групп разнородных элементов, с необязательными или множественными атрибутами. Использование суррогатного ключа как идентификатора позволяет сохранить традиционные преимущества сетевой модели: прямой доступ к данным, использование навигационных выражений в запросах. Однако теория операций групповой обработки данных по-прежнему представлена все той же реляционной алгеброй. Иными словами, использовать более высокую потенциальную мощность сетевой модели данных в настоящее время не представляется возможным из-за отсутствия соответствующего математического аппарата работы с множествами.

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

84.42.6.114 08:10, 22 декабря 2009 (UTC)Владимир Рыбинкин[ответить]

Пока ответ один: ознакомьтесь с правилами Википедия:ОРИСС. Евгений Мирошниченко 10:04, 22 декабря 2009 (UTC)[ответить]

Модель = теория?[править код]

Сомнительное определение: "модель - ... теория". Разве модель может быть теорией? Aroxing (обс.) 12:25, 3 сентября 2017 (UTC)[ответить]

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

Во-первых, термины определяют как единое целое, а не по словам. Есть термин, «модель данных», он определяется так-то и так-то. В этом определении, между прочим, даны все необходимые пояснения, оно не сводится к трём словам, «модель — это теория», как вы тут зачем-то пытаетесь представить. Не каждая модель — это теория. А вот «модель данных» — это вполне определённая специализированная теория.
Во-вторых, то, что границы понятий размыты, — не исключение, а повседневность. Попробуйте строго определить разницу между понятиями «метод», «подход», «методология». Или между «идея» и «концепция». Если вы, как я понял, преподаватель, вам проблемы демаркации, проблемы эпистемологии в целом должны быть хорошо известны. Как и то, что за исключением формальных аксиоматических теорий, практически ни одно определение ни в одной науке не является безупречно строгим. Их вводят объяснением, используя апофатический и катафатический подходы. Почитайте, например, статью Определение (логика). Евгений Мирошниченко 07:50, 4 сентября 2017 (UTC)[ответить]
    • При всё уважении, текущее содержание статьи выглядит довольно небрежным наброском. Вот за это модель равно теории цепляется глаз и далее нет желания читать. Попробую обновить текст по англоязычной версии, она намного убедительнее. Awserer (обс.) 03:07, 24 апреля 2022 (UTC)[ответить]
      То, что вы вставили в статью, даже на небрежный набросок не тянет. Сходу грубая ошибка, "модель данных" используется в значении "модель базы данных". И всё это по мусорным источникам. Евгений Мирошниченко 18:59, 24 апреля 2022 (UTC)[ответить]
      • Вы это серьёзно написали? Это, например, у Вас тоже мусорный источник? Нет, если Вы настаиваете, чтобы статья оставалась в текущем убогом состоянии, пусть остаётся. Тратить время на дискуссию не буду. Awserer (обс.) 14:17, 27 апреля 2022 (UTC)[ответить]