Привет!
funikovyuri
shuklin
может хоть вы на мой
вопрос ответите?
funikovyuriДалее, ОО модель данных (в терминах, например, UML) это классы, атрибуты и отношения. Так вот - не могли бы вы привести пример оо-модели которую бы нельзя или сложно было отобразить на реляционную? А то ваши соратники по оосубд, в приведенном вами топике, ссылались на отсутствие наследования в РБД - что говорит против их знаний в области проектирования РБД, но никак не против РБД как таковых.
Попробую ответить.
Сначала ответ теоретический. Если система равномощна в вычислительном плане машине Тьюринга - она может эмулировать любую другую машину Тьюринга. Отсюда следует, что начиная с некоторой сложности, система позволяет реализовать ВСЕ что угодно. Тоесть, на SQL можно реализовать сетевую архитектуру, а на ООБД можно эмулировать таблицы SQL. Все упирается только в цену, которая включает разработку (удобство программирования, тестирования, развертывания, ...) и эксплуатацию (перформанс, надежность,..) Интересно заметить, что комфорт программиста определяет стоимость разработки. Если задача естественнее ложиться на таблицы – возможно ее дешевле делать на РБД. Если на сеть – возможно дешевле ООБД.
Итак, чтобы продемонстрировать достоинства ООБД надо найти задачу, модель предметной области является сетью и / или требует наследования и полиморфизма. (Кстати версант не может продемонстрировать такие преимущества, так как они сами и признались, методы у объектов в БД не поддерживаются, тогда одного из удобнейших возможностей ОО - полиморфизма в FastObjects нет, мне странно, как можно не поддерживать полиморфизм в .NET Возможно Алексей что то напутал или недообъяснил и полиморфизм таки есть )
В качестве такой задачи можно предложить например векторный графический редактор типа Visio. Все графические объекты, которые потребуется хранить в БД, можно унаследовать от общего класса Widget. На прямую навигацию в ООБД естественным образом ложатся связи между графическими объектами.
Разрабатывать графический редактор для ООБД я в ближайшее время не планирую, поэтому приведу еще один пример, уже разработанный и внедренный в СООБЗ Cerebrum - БД конфигурации.
Итак, как мы знаем, все объекты в ООБД имеют свой уникальный ID по которому их можно быстро найти - это аналог PK c индексом. Само его наличие не дает преимуществ перед РБД. Однако возможность нарушать 1NF - хранить в одном атрибуте объекта список значений из этих ID позволяет реализовывать коллекции объектов использующих метод прямой навигации (что в РБД уже затруднительно, так как отношения один ко многими или составной ключ - это уже не один а несколько операций поиска по индексам, к тому же прямая навигация в таком случае ИМХО удобнее JOIN ).
Теперь упрощенная модель классов из наймспайс Cerebrum.Reflection
public class MemberDescriptor : Cerebrum.Integrator.GenericComponent
{
public string Name
public string DisplayName
public string Description
}
Названия пропертей говорят за себя Это базовый класс для описателей которые обладают свойсвами имя, дружественное имя и описание. Многие объекты могут иметь такие атрибуты, поэтому удобно наследовать такие объекты от MemberDescriptor.
public class AttributeDescriptor : MemberDescriptor
{
public Cerebrum.Runtime.NativeHandle AttributeTypeHandle
public System.Type AttributeType
public Cerebrum.Runtime.IConnector GetTypeDescriptor()
}
Дескриптор атрибута – описывает имя некоторого атрибута объекта. Он расширяет объект MemberDescriptor добавляя свойства AttributeType, AttributeTypeHandle а также метод GetTypeDescriptor()
AttributeType возвращает тип данного атрибута.
GetTypeDescriptor() возвращает объект-дескриптор этого же типа.
Например, для свойства Name объекта MemberDescriptor В ООБД создаются экземпляр объекта AttributeDescriptor с значениями свойств соответсвенно
Name = “Name”
DisplayName = “Name”
Description = “Object name”
AttributeType = typeof(System.String)
GetTypeDescriptor() = экземпляр TypeDescriptor описывающий System.String
Таким образом экземпляры класса AttributeDescriptor описывают свойства объектов, хранимых в ООБД, в том числе и свойства собственно класса AttributeDescriptor
public class TypeDescriptor : MemberDescriptor
{
public string QualifiedTypeName
public Cerebrum.Runtime.KernelObjectClass KernelObjectClass
public System.Type ComponentType
}
Описывает тип объекта.
Свойство QualifiedTypeName содержит строковое полное имя .NET объекта, например “System.String”
Свойство KernelObjectClass рассматривать не будем.
Свойство ComponentType возвращает typeof(QualifiedTypeName) тоесть .NET тип описываемый дескриптором
Свойства, унаследованные от MemberDescriptor тривиальны.
Для свойства QualifiedTypeName создается экземпляр AttributeDescriptor у которого
Name = “QualifiedTypeName”
DisplayName = “Qualified Type Name”
Description = “.NET Qualified Type Name”
AttributeType = typeof(System.String)
GetTypeDescriptor() = экземпляр TypeDescriptor описывающий System.String
Итак мы имеем несколько классов экземпляры которых описывают объекты, содержащиеся в ООБД и сами кстати (экземпляры) так же являются объектами находящимися в ООБД. Поэтому они описывают сами себя.
Можно заметить, что у объектов имеются совместимые атрибуты – например у многих объектов есть атрибут “Name” который описывает имя объекта. Объекты являющиеся экземплярами одного и того же класса имеют одинаковый список атрибутов.
Логично сгруппировать однотипные объекты в таблицы у которых колонки будут представлять атрибуты, а строки – собственно экземпляры объектов.
public class TableDescriptor : MemberDescriptor, System.ComponentModel.IListSource
{
public Cerebrum.Runtime.NativeVector GetSelectedAttributesVector()
public Cerebrum.Runtime.NativeVector GetSelectedComponentsVector()
public System.Type ComponentType
public Cerebrum.Data.TableView DefaultView
}
Описывает таблицу из экземпляров объектов. Свойства унаследованные от MemberDescriptor соответсвенно описывают имя, дружественное имя и описание данной таблицы.
Метод GetSelectedAttributesVector возвращает коллекцию атрибутов - колонок таблицы, этому методу соответсвует экземпляр AttributeDescriptor у которого
Name = “SelectedAttributes”
DisplayName = “SelectedAttributes”
Description = “SelectedAttributes collection”
AttributeType = typeof(System.ComponentModel.IBindingList)
Метод GetSelectedComponentsVector возвращает коллекцию объектов - строк таблицы, этому методу соответсвует экземпляр AttributeDescriptor у которого
Name = “SelectedComponents”
DisplayName = “SelectedComponents”
Description = “SelectedComponents collection”
AttributeType = typeof(System.ComponentModel.IBindingList)
Все экземпляры AttributeDescriptor перечислинны в таблице TableDescriptor.Name = “Attributes”
Все экземпляры TypeDescriptor перечислинны в таблице TableDescriptor.Name = “Types”
Все экземпляры TableDescriptor перечислинны в таблице TableDescriptor.Name = “Tables”
При этом экземпляры класса AttributeDescriptor.Name = “Name” разумеется содержаться в коллекции строк таблицы Attributes а так же в коллекциях атрибутов (колонок) таблиц “Attributes”, “Types” и “Tables”
Экземпляр класса TableDescriptor.Name = “Tables” хранится в своей же коллекции строк таблицы (SelectedComponents)
Надо заметить, что экземпляры объекты могут одновременно входить в разные таблицы при этом важно чтоб они поддерживали все атрибуты, являющиеся колонками таблиц в которые они входят в качестве строк.
Данным примером мы продемонстрировали что на основе ООБД возможна эмуляция РБД.
В связи с этим от апологетов РБД я бы хотел увидеть эмуляцию РБД средсвами РБД допускающую создания новых "виртуальных" таблиц на основе некоторой фиксированной по колличеству таблиц структуры БД. Тоесть, при создании новой виртуальной таблицы новая таблица в БД не создается.
С уважением, Дмитирй.
