Прототипная модель данных

в 3:45, , рубрики: Анализ и проектирование систем, Веб-разработка, иерархические структуры, Модель данных, прототипы, разработка, метки: , ,

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

Прототипная модель данных

Структура

Объект является элементарной сущностью, имеющей имя, значение и некоторые другие, стандартные для всех объектов, атрибуты. Назвать объект можно по-разному, но как его назовешь, то он и будет означать. Значение является скалярным, им можно представить числа, адреса, даты, пути на файлы, текст и многое другое. Длина значения не ограничивается. Элементарность объектов обеспечивает гибкость построения сложных структур.

Для представления сложных структур данных, таких как каталоги, товар с множеством свойств, объекты структурируются в иерархию. Каждый объект способен иметь в подчинении неограниченное количество объектов, при этом быть подчиненным только для одного иного объекта, которого нет у него в подчинении. Обычная иерархия из объектов. С помощью иерархии человечество издавна структурирует познания о реальном мире, это естественный и удобный способ представления информации. Иерархия во всем.

Прототипная модель данных

Но одной иерархией не смоделировать объекты реального или воображаемого мира. Например, товар не поместить одновременно в несколько каталогов. Необходимо связывание объектов из разных ветвей иерархии.

Наследование

На этом этапе зарождается прототипная модель. Кроме имени и значения каждый объект без исключений может иметь ссылку на любой другой объект, где бы тот не находился. Именно ссылкой образуется связь с прототипом. Ссылка реализуется дополнительным атрибутом объекта, представляющим идентификатор прототипа. Объект может иметь только одну ссылку.

Теперь в нужный каталог можно добавить существующий товар из другого каталога, создав объект товара, прототипируя его от товара второго каталога. Фактически появится новый товар, но без дублирования свойств (подчиненных свойств товара). Обращаясь к новому товару, мы сможем оперировать свойствами его прототипа.

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

Прототипная модель данных

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

Логика

Недостаточно иметь только структуры данных. Их необходимо оживить, наделив объекты логикой. Логика реализуется методами (функциями) объекта. Могут быть методы проверки объекта перед сохранением, методы обработки запросов, формирования отображения и любые другие. Всё зависит от назначения объекта. При прототипировании новый объект вместе со свойствами прототипа наследует и его логику, естественно, с возможностью дополнять и переопределять её.

Идентификация

Для идентификации объектов обычно используются суррогатные ключи, например целые числа. Ввиду отсутствия границ связывания одного объекта с любым другим, уникальность ключа должна обеспечиваться в рамках всей структуры данных. Поэтому идеально иметь неограниченный диапазон значений для ключа. Точнее сказать недостижимый предел значений в рамках проектируемой системы. Но проблема не в этом, а в существовании объектов, которые не могут постоянно обладать суррогатным ключом, так как сами же создаются в момент обращения к ним и на время их использования. В базе данных их нет, значит, обратиться к ним по ключу нет возможности.

Существует два способа реализации прототипирования. В первом способе прототип полностью копируется, новый объект получает копии всех подчиненных прототипа. В случаи изменения прототипа, необходимо осуществлять обновление всех прототипированных объектов и их подчиненных, которые не были ещё переопределены. Минусом является сложность обновления и дублирование данных, зато можем идентифицировать любой объект.

Второй способ предполагает только установку связи с прототипом. Не нужно ничего копировать и обновлять. Но когда оперируем объектом, имеющим прототип, и обращаемся к подчиненным прототипа, эти подчиненные должны восприниматься подчиненными оперируемого объекта. В случаи модификации таких подчиненных, изменения ни в коем случаи не должны коснуться прототипа. Измененные объекты должны сохраниться как новые подчиненные оперируемого объекта. Пока объекты не сохранены, они являются виртуальными, временно создаются, прототипируясь от соответствующих подчиненных прототипа. К таким объектам нельзя обратиться напрямую, необходимо обращаться к ним от их родителя, так как от родителя зависит их существование.

Прототипная модель данных

Какие бы не были объекты, их все равно нужно идентифицировать. Необходима возможность сослаться на объект (предопределить связь) даже если объект отсутствует. Здесь поможет использование именований объектов, если сделать их имена уникальными в рамках одного уровня вложенности. Тогда к объектам можно обращаться через путь на них, как на файлы.

P.S.

Прототипная модель данных отличается своей гибкостью и естественностью строения. Не нужно городить вспомогательных сущностей, например, для реализации связей «многие-ко-многим», проектировать структуры данных, пытаясь предусмотреть все варианты развития проекта, ведь в случаи чего нужно будет только перенести данные в другую ветку, всё равно, что сделать перестановку в комнате без переделывания её планировки. Но, ввиду отсутствия готовых решений, прототипную модель приходится моделировать на других моделях данных. Например, на реляционной, от чего проявляются различные проблемы и ограничения. Оставлю этот вопрос открытым для обсуждения. Если кто возьмется за создания СУБД с прототипной моделью, позовите меня в команду. :)

Автор: boolive

Поделиться

* - обязательные к заполнению поля