Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 31   вперед  Ctrl
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Александр Савинов
Что такое ссылки на строки я понимаю. А вот что такое ссылки на колонки?

Точнее говоря коллекция ссылок на объекты с метаинформацией о колонках таблицы (они же описатели аттрибутов, или просто аттрибуты). Эти метаописатели так же являются объектами(==узлами).

Александр Савинов

shuklin
Ссылки на строки - это в том числе ссылки на объекты(наследование)

А что еще это может быть?

Хотел сказать, что строки таблицы это объекты, унаследованные от System.Object Т.к. все унаследованно от объектов, ничего кроме объектов это быть не может.

Александр Савинов

shuklin
Следовательно ссылки на строки могут ссылаться и на таблицы (что и происходит).
Т.е. таблицы это обычные сущности? В частности, они могут участвовать в запросах?

Таблица это объект. Кроме прочего, содержит ссылки на объект-коллекцию указателей на описатели колонок и на коллекцию указателей на объекты, представляющие строки.
Про запросы сложнее. На данный момент собственного декларативного языка в системе нет. Есть только императивный C#. Можно ли считать конструкции C# запросами - вопрос не имеющий имхо практического смысла. Таблицы могут участвовать в обработке на равне с любыми другими объектами.

Александр Савинов

shuklin
Итак имеем цикл таблица->строки->таблица

это цикл на уровне схемы.

А как на уровне схемы можно ссылаться на конкретную строку? В моем понимании, на уровне схемы существуют только таблицы.

На уровне схемы на конкретную - конечно нельзя. Но таблицы не есть базовое понятие схемы. Это уже производное понятие. Таблица это 3 узла. Узел объекта "таблица", узел коллекции "колонки", узел коллекции "строки". Таким образом узел "строки" ссылаясь на объект ссылается и на узел "таблица", которая ссылается на узел "строки".

shuklin
цикл на уровне данных:

таблица "таблицы" содержит себя как свою строку.

аттрибут "имя" имеет аттрибут имя = "имя" и описывает этот свой собственный аттрибут.

Похоже, я запутался.
Что здесь первично? И что добавляется потом?[/quot]
Здесь ничего не первично. Это тавталогия. Т.к. в цикле нет отрицания, то парадокса Рассела не возникает. Тавталогия самодостаточна для своего существования и самоописания. Она добавляется поэтапно. Сначала создаются все ее узлы, затем устанавливаются связи между этими узлами.
14 дек 06, 16:22    [3537493]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов

хорошо или плохо иметь циклы в ссылочной структуре.
Дык с удовольствием не имели бы, но
Каждый СОТРУДНИК может РАБОТАЕТ_В один ОТДЕЛ
Каждый ОТДЕЛ должен ИМЕЕТ_НАЧАЛЬНИКА один СОТРУДНИК
14 дек 06, 16:36    [3537622]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
shuklin
Александр Савинов

shuklin
Итак имеем цикл таблица->строки->таблица

это цикл на уровне схемы.

А как на уровне схемы можно ссылаться на конкретную строку? В моем понимании, на уровне схемы существуют только таблицы.

На уровне схемы на конкретную - конечно нельзя. Но таблицы не есть базовое понятие схемы. Это уже производное понятие. Таблица это 3 узла. Узел объекта "таблица", узел коллекции "колонки", узел коллекции "строки". Таким образом узел "строки" ссылаясь на объект ссылается и на узел "таблица", которая ссылается на узел "строки".


То есть примерно так:

Table = <Columns, Rows>
Columns = {c1, c2, ...}
Rows = {r1, r2, ...}

Отсюда я вижу, следующую связь:

Table -> Rows -> ?

Каким образом и зачем строке указывать на таблицу?

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

shuklin
Александр Савинов

shuklin
цикл на уровне данных:

таблица "таблицы" содержит себя как свою строку.

аттрибут "имя" имеет аттрибут имя = "имя" и описывает этот свой собственный аттрибут.

Похоже, я запутался.
Что здесь первично? И что добавляется потом?

Здесь ничего не первично. Это тавталогия. Т.к. в цикле нет отрицания, то парадокса Рассела не возникает. Тавталогия самодостаточна для своего существования и самоописания. Она добавляется поэтапно. Сначала создаются все ее узлы, затем устанавливаются связи между этими узлами.

Я имел в виду вот что. Таблица может существовать без колонок и без строк. Значит, она первична. Колонку и строку без таблицы создать нельзя. База данных может существовать без таблиц, но не наоборот. Ну вроде бы здесь я разобрался (как мне кажется).
14 дек 06, 16:49    [3537781]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
ModelR
Александр Савинов

хорошо или плохо иметь циклы в ссылочной структуре.
Дык с удовольствием не имели бы, но
Каждый СОТРУДНИК может РАБОТАЕТ_В один ОТДЕЛ
Каждый ОТДЕЛ должен ИМЕЕТ_НАЧАЛЬНИКА один СОТРУДНИК

Стандартный случай. Без таких примеров не было бы и проблемы, конечно.

Можно сделать несколько комментариев.

1. Если речь идет о настоящей практике, то можно и делать. Для РСУБД этот вопрос безразличен, а то, что нам нужно мы спокойно получим с помощью SQL.

2. Если хочется убрать цикл и сделать дизайн более чистым, то можно поступить так:
2.1. Ввести поле с ролью сотрудника (начальник он или нет).

ОТДЕЛ
|
СОТРУДНИК(..., BOOL isBoss, ...)

2.2. Ввести таблицу связей ОС. Тогда либо эта таблица ОС, либо СОТРУДНИК будет определять его роль.

ОТДЕЛ СОТРУДНИК
\ /
ОС
Первый вариант попроще будет, второй более гибкий.

Если БД не использует структуры связей (как современные РСУБД), то отсутствие циклов это не догма, а рекомендация. Если БД существенно опирается на структуру, тогда всегда есть средства убрать циклы и одновременно сделать дизайн чище.
14 дек 06, 17:01    [3537884]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
? ?
Guest
ModelR
Александр Савинов

хорошо или плохо иметь циклы в ссылочной структуре.
Дык с удовольствием не имели бы, но
Каждый СОТРУДНИК может РАБОТАЕТ_В один ОТДЕЛ
Каждый ОТДЕЛ должен ИМЕЕТ_НАЧАЛЬНИКА один СОТРУДНИК

А у меня сотрудники создают и изменяют экземпляры, и каждый экземпляр помнит своего создателя и последнего редактора. Они же, сотрудники, работают в этих экземплярах и являются начальниками.
Что поделать, мир несовершенен, дизайнер плох...
14 дек 06, 17:06    [3537929]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
!
Guest
shuklin

Здесь ничего не первично. Это тавталогия. Т.к. в цикле нет отрицания, то парадокса Рассела не возникает. Тавталогия самодостаточна для своего существования и самоописания. Она добавляется поэтапно. Сначала создаются все ее узлы, затем устанавливаются связи между этими узлами.


Это бесконечный цикл тафтологий.
Вы предлагаете распутывать его на уровне АПП сервера?
14 дек 06, 17:06    [3537932]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Александр Савинов

То есть примерно так:

Table = <Columns, Rows>
Columns = {c1, c2, ...}
Rows = {r1, r2, ...}

Отсюда я вижу, следующую связь:

Table -> Rows -> ?

Table -> Rows -> Objects
а так как таблица тоже Object то Rows имеет право указывать и на таблицы.

Александр Савинов
Каким образом и зачем строке указывать на таблицу?

Таблица есть объект, строки есть объекты, следовательно таблицы могут быть строками. Это удобно.

Александр Савинов
Это ведь внутрення реализация СУБД, а мы говорим о логической организации данных, например, сущности одного типа ссылаются на сущности другого типа, которые в свою очередь, ссылаются на первые.

Нет, это не внутренняя реализация СУБД, это именно логическая модель РСУБД. А СУБД сетевая, и оперирует узлами и связями. В СУБД нет таблиц, строк, колонок, там только объекты==узлы и связи между ними. Сущность таблица ссылается на сущность "коллекция строк" которая ссылается на сущность "любой объект", таблица будучи объектом попадает в любой объект. Возникает кольцо на уровне схемы сетевой БД.


Александр Савинов
Я имел в виду вот что. Таблица может существовать без колонок и без строк. Значит, она первична. Колонку и строку без таблицы создать нельзя.

Колонка существует отдельно от таблицы, и входит одновременно в многие таблицы. Продолжая пример с колонкой==аттрибутом имя.

Колонка метаинформация об аттрибуте <имя> является объектом у которого есть аттрибут имя описываемый колонкой метаинформации об аттрибуте <имя>, значение этого аттрибута <имя> у этого объекта равен строке "Name", будучи объектом этот объект является строкой таблицы "Attributes" которая будучи объектом является строкой таблицы "Tables" и содержит в своей коллекции колонок некоторые метаописатели колонок, в том числе тот самый объект-аттрибут-имя, который в свою очередь является одновременно и колонкой таблицы "Tables" и описывает у таблицы "Attributes" и ее имя и имя таблицы "Tables" еще кучу имен других таблиц и других объектов и тд и тп.

А есть еще описатели типов, которые описывают эти все типы, и конечно же самих себя, и у них тоже есть имя, ...
14 дек 06, 17:09    [3537956]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
!
Это бесконечный цикл тафтологий.
Вы предлагаете распутывать его на уровне АПП сервера?
Его вообще не нужно распутывать. Тавтология самодостаточна. И этот бесконечный их цикл это их достоинство. Их можно просто с пользой использовать.
14 дек 06, 17:11    [3537973]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
shuklin
Александр Савинов

То есть примерно так:

Table = <Columns, Rows>
Columns = {c1, c2, ...}
Rows = {r1, r2, ...}

Отсюда я вижу, следующую связь:

Table -> Rows -> ?

Table -> Rows -> Objects
а так как таблица тоже Object то Rows имеет право указывать и на таблицы.

Правильно ли я понял, что в обычных терминах данное обобщение состоит в том, что в качестве свойств объектов могут быть таблицы (обычно это нельзя делать). Если так, то какой тип колонки должен быть у такого свойства?

shuklin
Александр Савинов
Каким образом и зачем строке указывать на таблицу?

Таблица есть объект, строки есть объекты, следовательно таблицы могут быть строками. Это удобно.

У меня еще осталось сомнение в том, указывает ли на таблицу:

- одно свойство строки (имеющее, скажем, тип Table), или

- вся таблица включается в другую в качестве строки (тогда какая схема у родительской таблицы)

Правильно я записал ниже?

MyTable = <MyColumns, MyRows>
MyColumns = {c1="String", c2="Table", c3="Integer"}
MyRows = { r1=<"a", MyTable, 234>, r2=<"b",YourTable, 345> }

Здесь две строки ссылаются на две разные таблицы во втором поле.
14 дек 06, 17:24    [3538055]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
shuklin
Александр Савинов
Это ведь внутрення реализация СУБД, а мы говорим о логической организации данных, например, сущности одного типа ссылаются на сущности другого типа, которые в свою очередь, ссылаются на первые.

Нет, это не внутренняя реализация СУБД, это именно логическая модель РСУБД. А СУБД сетевая, и оперирует узлами и связями. В СУБД нет таблиц, строк, колонок, там только объекты==узлы и связи между ними. Сущность таблица ссылается на сущность "коллекция строк" которая ссылается на сущность "любой объект", таблица будучи объектом попадает в любой объект. Возникает кольцо на уровне схемы сетевой БД.

Понял. Я бы назвал это циклом на физическом уровне организации. Объект ссылается на физический контекст (контейнер), в котором он существует. Этот вопрос двойственен логической структуре, но на самом деле менее разработан (я бы сказал вообще почти не разработан).
14 дек 06, 17:35    [3538128]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
4321
Member [заблокирован]

Откуда:
Сообщений: 3573
Александр Савинов
Если БД не использует структуры связей (как современные РСУБД), то отсутствие циклов это не догма, а рекомендация.
чья? (уже не говоря о том, чем обоснованная)
Александр Савинов
Если БД существенно опирается на структуру, тогда всегда есть средства убрать циклы и одновременно сделать дизайн чище.
у вас не БД опирается, а синтаксис.
Т.ч. выражайтесь точнее: если мы вводим синтаксис запросов, не разрешающий циклические ссылки на уровне схемы (т.е. работающий только при условии определения "порядка [введения] сущностей [в схему] в схеме"), то мы вынуждены вставать в позу [...], диктуемую этим синтаксисом.

Вот и ответьте на вопрос: зачем вставать <вырезано цензурой> ...принимать синтаксис, диктующий вам же неудобную позу?

К тому же, чтобы разобраться в синтаксисе сложного запроса мне придется не только смотреть его текст (и текст определения таблиц), но и просмотреть всю схему ("иерархию" сущностей). Если бы был обозначен хоть какой-то бонус, то еще можно бы было оценивать мои потери vs приобретений при навязываемом вами выборе. Пока же видны только потери.
14 дек 06, 17:40    [3538175]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
shuklin
Александр Савинов
Я имел в виду вот что. Таблица может существовать без колонок и без строк. Значит, она первична. Колонку и строку без таблицы создать нельзя.

Колонка существует отдельно от таблицы, и входит одновременно в многие таблицы.

Зачем нужно, чтобы колонка входила во многие таблицы? Я вижу только одно объяснение: это не колонка, а домен (область значений). Различие между колонкой и доменом в том, что колонки не могут существовать без таблиц, поскольку это их атрибут, а у каждой таблицы свои уникальные колонки (поля). А домен это собственно и есть таблица. Каждой колонке надо приписать домен. Возможно так и есть. Я просто хочу уточнить.

shuklin
Колонка метаинформация об аттрибуте <имя> является объектом у которого есть аттрибут имя описываемый колонкой метаинформации об аттрибуте <имя>, значение этого аттрибута <имя> у этого объекта равен строке "Name", будучи объектом этот объект является строкой таблицы "Attributes" которая будучи объектом является строкой таблицы "Tables" и содержит в своей коллекции колонок некоторые метаописатели колонок, в том числе тот самый объект-аттрибут-имя, который в свою очередь является одновременно и колонкой таблицы "Tables" и описывает у таблицы "Attributes" и ее имя и имя таблицы "Tables" еще кучу имен других таблиц и других объектов и тд и тп.

А есть еще описатели типов, которые описывают эти все типы, и конечно же самих себя, и у них тоже есть имя, ...

Ну вроде бы у меня складывается картина. Вы расширили модель, открыв нижний уровень организации. В частности, легализовали статус таблицы как объектов, колонок как объектов и соответствующие средства их поддержки, т.е. мета-информацию. Правильно?
14 дек 06, 17:43    [3538203]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Александр Савинов

Правильно ли я понял, что в обычных терминах данное обобщение состоит в том, что в качестве свойств объектов могут быть таблицы (обычно это нельзя делать). Если так, то какой тип колонки должен быть у такого свойства?

Да, могут быть таблицы значениями свойств. Object при желании можно типизировать более строго.

Александр Савинов

- одно свойство строки (имеющее, скажем, тип Table)

Это разрешено, будет работать, но за не нужностью в конкретных сценариях готовых прецидентов, доступных к скачке нет.

Александр Савинов

- вся таблица включается в другую в качестве строки (тогда какая схема у родительской таблицы)

Да. В основном это так.

Александр Савинов

Правильно я записал ниже?

MyTable = <MyColumns, MyRows>
MyColumns = {c1="String", c2="Table", c3="Integer"}
MyRows = { r1=<"a", MyTable, 234>, r2=<"b",YourTable, 345> }

Здесь две строки ссылаются на две разные таблицы во втором поле.


Так можно, но схема БД конфигурации Cerebrum другая. Ща изображу фрагмент.

Tables = <NameAttr="Tables", DefTypeAttr=TableType, ColumnsAttr=TablesColumns, RowsAttr=TablesRows>
TablesColumns= {c1=NameAttr, c2=DefTypeAttr, c3=ColumnsAttr, c4=RowsAttr}
TablesRows= { r1=Tables , r2=Attributes, r3 = Types }

Attributes= <NameAttr="Attributes", DefTypeAttr=AttrType, ColumnsAttr=AttributesColumns, RowsAttr=AttributesRows>
AttributesColumns = {c1=NameAttr, c2=DefTypeAttr}
AttributesRows= { r1=NameAttr, r2=DefTypeAttr, r3=SystemTypeAttr}

Types = <NameAttr="Types", DefTypeAttr=TypeType, ColumnsAttr=TypesColumns, RowsAttr=TypesRows>
AttributesColumns = {c1=NameAttr, c2=SystemTypeAttr}
AttributesRows= { r1=TypeType, r2=TableType, r3=AttrType, r4 = StringType}

NameAttr = <NameAttr="Name", DefTypeAttr = StringType>
DefTypeAttr = <NameAttr="DefType", DefTypeAttr = TypeType>
SystemTypeAttr= <NameAttr="SystemType", DefTypeAttr = StringType>
ColumnsAttr = ...
RowsAttr = ...

TypeType = <NameAttr="Type", SystemTypeAttr= "Cerebrum.Integrator.Reflection.TypeDescriptor">
TableType = <NameAttr="Type", SystemTypeAttr= "Cerebrum.Integrator.Reflection.TableDescriptor">
AttrType = <NameAttr="Type", SystemTypeAttr= "Cerebrum.Integrator.Reflection.IAttributeDescriptor">
StringType = <NameAttr="Type", SystemTypeAttr= "System.String">

В текущем архиве SDK, доступном для скачивания, описание этой структуры доступно в формате XML как Cerebrum\Integrator\DATA\Script\clean_ui_01.xvmg
14 дек 06, 17:52    [3538264]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Александр Савинов
shuklin
Колонка существует отдельно от таблицы, и входит одновременно в многие таблицы.

Зачем нужно, чтобы колонка входила во многие таблицы? Я вижу только одно объяснение: это не колонка, а домен (область значений). Различие между колонкой и доменом в том, что колонки не могут существовать без таблиц, поскольку это их атрибут, а у каждой таблицы свои уникальные колонки (поля). А домен это собственно и есть таблица. Каждой колонке надо приписать домен. Возможно так и есть. Я просто хочу уточнить.

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

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

Да. Или если выразится по другому, я для удобства смоделировал нечто похожее на РСУБД средствами сетевой СУБД. При этом исходил из собственного удобства использования результата для нужд сетевой СУБД, а не следования канонам построения РСУБД. Т.е. полученная "РСУБД" позволяет хранить в себе фрагмент схемы сетевой СУБД на основе которой и реализована. Это очень удобно для экспорта-импорта в XML. В битах же не будешь ковырятся. Большинство экземпляров имеют жесткую комплектацию аттрибутов, известных на момент дизайна, поэтому их коллекции удобно рассматривать как таблицы. Однотипные экземпляры удобно помещать в одни и теже таблицы с единым интерфейсом == шапкой.
14 дек 06, 18:04    [3538348]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
Александр Савинов
ModelR
Александр Савинов

хорошо или плохо иметь циклы в ссылочной структуре.
Дык с удовольствием не имели бы, но
Каждый СОТРУДНИК может РАБОТАЕТ_В один ОТДЕЛ
Каждый ОТДЕЛ должен ИМЕЕТ_НАЧАЛЬНИКА один СОТРУДНИК

Стандартный случай. Без таких примеров не было бы и проблемы, конечно.

Можно сделать несколько комментариев.
[...]
2. Если хочется убрать цикл и сделать дизайн более чистым, то можно поступить так:
2.1. Ввести поле с ролью сотрудника (начальник он или нет).

ОТДЕЛ
|
СОТРУДНИК(..., BOOL isBoss, ...)

2.2. Ввести таблицу связей ОС. Тогда либо эта таблица ОС, либо СОТРУДНИК будет определять его роль.

ОТДЕЛ СОТРУДНИК
\ /
ОС
Первый вариант попроще будет, второй более гибкий.

Если БД не использует структуры связей (как современные РСУБД), то отсутствие циклов это не догма, а рекомендация. Если БД существенно опирается на структуру, тогда всегда есть средства убрать циклы и одновременно сделать дизайн чище.

2.1. Не эквивалетно:
(а) Исходная ER модель не запрещает сотруднику одного отдела возглавлять другой. BOOL isBoss очевидно признак начальника строго того отдела, где работает сотрудник.
(б) Исходная ER модель запрещает много боссов одного отдела. isBoss очевидно нет.

2.2. Не эквивалетно: В исходной ER модели запрещено отношение многие-ко-многим между. СОТРУДНИК и ОТДЕЛ. ОС этого не запрещает.

ИМХО Отсутствие циклов - также слишком сильное ограничение для реальных задач.
Традиционно никогда в сетевой модели (CODASYL) циклы не запрещали.

Что мешает явно указывать связь?

Каждый СОТРУДНИК может РАБОТАЕТ_В один ОТДЕЛ
Каждый ОТДЕЛ должен ИМЕЕТ_НАЧАЛЬНИКА один СОТРУДНИК
Каждый ОТДЕЛ может ИМЕЕТ_КУРАТОРА один СОТРУДНИК

Отдел, где работает начальник отдела, где работает куратор отдела, в котором работает Вася:
Вася.РАБОТАЕТ_В.ИМЕЕТ_КУРАТОРА.РАБОТАЕТ_В.ИМЕЕТ_НАЧАЛЬНИКА.РАБОТАЕТ_В
14 дек 06, 19:26    [3538675]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ModelR
Member

Откуда: Нижний Новгород
Сообщений: 1798
shuklin
Большинство экземпляров имеют жесткую комплектацию аттрибутов, известных на момент дизайна, поэтому их коллекции удобно рассматривать как таблицы. Однотипные экземпляры удобно помещать в одни и теже таблицы с единым интерфейсом == шапкой.
Во. А то спорят таблица - это класс, таблица это переменная.
Таблица = объект типа коллекция однотипных векторов объектов.
ИМХО.
14 дек 06, 19:37    [3538708]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
ModelR
shuklin
Большинство экземпляров имеют жесткую комплектацию аттрибутов, известных на момент дизайна, поэтому их коллекции удобно рассматривать как таблицы. Однотипные экземпляры удобно помещать в одни и теже таблицы с единым интерфейсом == шапкой.
Во. А то спорят таблица - это класс, таблица это переменная.
Таблица = объект типа коллекция однотипных векторов объектов.
ИМХО.

Уточнение, ИМХО:
Таблица = объект типа коллекция векторов объектов c совместимым интерфейсом. Несовместимости допустимо сглаживать NULL
14 дек 06, 19:48    [3538732]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
ModelR
Александр Савинов
ModelR
Александр Савинов

хорошо или плохо иметь циклы в ссылочной структуре.
Дык с удовольствием не имели бы, но
Каждый СОТРУДНИК может РАБОТАЕТ_В один ОТДЕЛ
Каждый ОТДЕЛ должен ИМЕЕТ_НАЧАЛЬНИКА один СОТРУДНИК

Стандартный случай. Без таких примеров не было бы и проблемы, конечно.

Можно сделать несколько комментариев.
[...]
2. Если хочется убрать цикл и сделать дизайн более чистым, то можно поступить так:
2.1. Ввести поле с ролью сотрудника (начальник он или нет).

ОТДЕЛ
|
СОТРУДНИК(..., BOOL isBoss, ...)

2.2. Ввести таблицу связей ОС. Тогда либо эта таблица ОС, либо СОТРУДНИК будет определять его роль.

ОТДЕЛ СОТРУДНИК
\ /
ОС
Первый вариант попроще будет, второй более гибкий.

Если БД не использует структуры связей (как современные РСУБД), то отсутствие циклов это не догма, а рекомендация. Если БД существенно опирается на структуру, тогда всегда есть средства убрать циклы и одновременно сделать дизайн чище.

2.1. Не эквивалетно:
(а) Исходная ER модель не запрещает сотруднику одного отдела возглавлять другой. BOOL isBoss очевидно признак начальника строго того отдела, где работает сотрудник.
(б) Исходная ER модель запрещает много боссов одного отдела. isBoss очевидно нет.

2.2. Не эквивалетно: В исходной ER модели запрещено отношение многие-ко-многим между. СОТРУДНИК и ОТДЕЛ. ОС этого не запрещает.


Совершенно верно. Все три варианта обладают разными свойствами.

ModelR
ИМХО Отсутствие циклов - также слишком сильное ограничение для реальных задач.


Сильное, но оно того стоит.

ModelR
Традиционно никогда в сетевой модели (CODASYL) циклы не запрещали.

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

ModelR
Что мешает явно указывать связь?

Каждый СОТРУДНИК может РАБОТАЕТ_В один ОТДЕЛ
Каждый ОТДЕЛ должен ИМЕЕТ_НАЧАЛЬНИКА один СОТРУДНИК
Каждый ОТДЕЛ может ИМЕЕТ_КУРАТОРА один СОТРУДНИК


Потому что нельзя ссылаться на то, что еще не существует. ОТДЕЛ может существовать без СОТРУДНИКа, поскольку это контейнер для них. Мы создаем отдел. Какие сотрдуники? Какие кураторы? Они еще не родились. А если бы они родились раньше, то, соответственно, не могли бы ссылаться на отделы.

Ссылка на что-то это ссылка на родительский контейнер (группа). Если сотрудник ссылается на отдел, то он принадлежит этой группе. Если есть цикл, то это значит цикл вложенности. А это не есть хорошо.

Запрет на циклы это не цель, а средство, т.е. мы делаем это вынужденно, чтобы достигнуть чего-то большего.

Я еще поразмышляю над этим примером, поскольку он очень характерен. Возможно, я придумаю, как сохранить такой цикл, придав ему нужную интерпретацию.
14 дек 06, 20:52    [3538844]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
[censored]
Guest
Александр Савинов
Потому что нельзя ссылаться на то, что еще не существует. ОТДЕЛ может существовать без СОТРУДНИКа, поскольку это контейнер для них.

Да, а брак - это контейнер для производства сотрудников...
14 дек 06, 21:29    [3538910]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
shuklin
Member

Откуда: Харьков
Сообщений: 799
Александр Савинов

Одна из причин, почему они нас покинули.

Если это и причина, то имхо одна из последних. У них там есть такие жутик как порядок записей => предыдущая и следующая запись.

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

В этом Кодд сделал прорыв, убрал порядок и навигацию между записями одного контейнера.
14 дек 06, 23:17    [3539119]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
Александр Савинов
Member

Откуда:
Сообщений: 173
shuklin
Александр Савинов

Одна из причин, почему они нас покинули.

Если это и причина, то имхо одна из последних. У них там есть такие жутик как порядок записей => предыдущая и следующая запись.

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

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

shuklin
В этом Кодд сделал прорыв, убрал порядок и навигацию между записями одного контейнера.

Да, это сильный шаг. Но часто забывают, что никто это не признавал и били его сильно очень. Лет этак 10 все на месте стояло. Без Дейта ничего может и не вышло бы (в таком виде). Кодд это как Маркс, а Дейт это Ленин :-)

Но логика развития неумолима. Любая теория проходит от начального творческого периода к времени, когда она превращается в догму и религию. И сейчас мы это наблюдаем на примере РМД. Ну вернее, не теория конечно, а люди, которые думают, что они обрели монополию на истину и могу судить об истине, прикрываясь именем Кодда (за примерами далеко ходить не надо). Диалектика, однако...
14 дек 06, 23:41    [3539147]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
U-gene
Member

Откуда: Москва. Россия
Сообщений: 1576
Любая теория проходит от начального творческого периода к времени, когда она превращается в догму и религию.
ИМХО нет. Хорошая теория тем и хороша. что вне завсимости от того, как её интерпретируют или реализуют, остается верной.Возьмиет законы Ньютона, теорему Пифагора и .т.п. :) Правда, потом выяснилось, что это всего лишь частные случаи в определнных условиях (Ньютон - малые скорости, Пифагор - на плоскости), но никто не отменил то, что в этих частных случаях эти теории верны.

Перейдем ближе к нашим баранам. Я уже сказал, что многие (точнее большинство) воспринмает РМД через используемую систему. Находя ограничения,неудобства и глюки используемой системы они говорят - о! РМД ограничена, она неудобна,ее нужно как-то на что-то заменить. При этом пытаясь перетасовывать всё те же, известные десятилетия назад понятия типа"ссылка", "контейнер", "список" в "новом" и конечно же "единственно правильном" порядке. Потом эти люди начинают спроить друг с другом пытаясь выставить свой "порядок" "правильнее" чужого (за примерами далеко ходить не надо).

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

Другими словами Ваши желания не требуют отказа от РМД и более того - выражаются в терминах РМД.

Конечно, можно сетовать на то, что что РМД неудобна. Вы еще посетуйте на то, что арифметика неудобна - хотя бы потому что в ней нет операции нахождения корней квадратного тречлена или определения среднеквадратичного отклонения (а ведь кое кому эти возможности крайне важны!). В общем "Вы не любите РМД? - Вы просто не умеете её готовить".
15 дек 06, 01:20    [3539249]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ЙОМОЙО
Guest
Идея товарища Савинова хороша но не доведена до логического конца
Имеем
CREATE TABLE "DBA"."t1" (
    "t1f1"                           integer NOT NULL
   ,"t1f2"                           char(30) NULL
   ,PRIMARY KEY ("t1f1") 
)
go

CREATE TABLE "DBA"."t2" (
    "t2f1"                           integer NOT NULL
   ,"t2f2"                           integer NULL
   ,"t2f3"                           char(30) NULL
   ,PRIMARY KEY ("t2f1") 
)
go

CREATE TABLE "DBA"."t3" (
    "t3f1"                           integer NOT NULL
   ,"t3f2"                           integer NULL
   ,"t3f3"                           char(30) NULL
   ,PRIMARY KEY ("t3f1") 
)
go

CREATE TABLE "DBA"."t4" (
    "t4f1"                           integer NOT NULL
   ,"t4f2"                           integer NULL
   ,"t4f3"                           char(30) NULL
   ,PRIMARY KEY ("t4f1") 
)
go


ALTER TABLE "DBA"."t2"
    ADD FOREIGN KEY "t1" ("t2f2")
    REFERENCES "DBA"."t1" ("t1f1")
    
go

ALTER TABLE "DBA"."t3"
    ADD FOREIGN KEY "t2" ("t3f2")
    REFERENCES "DBA"."t2" ("t2f1")
    
go

ALTER TABLE "DBA"."t4"
    ADD FOREIGN KEY "t3" ("t4f2")
    REFERENCES "DBA"."t3" ("t3f1")
    
go




Хотим получить
SELECT "DBA"."t1"."t1f2"
FROM ( ( "DBA"."t1" JOIN "DBA"."t2" ON "DBA"."t1"."t1f1" = "DBA"."t2"."t2f2" )
 JOIN "DBA"."t3" ON "DBA"."t2"."t2f1" = "DBA"."t3"."t3f2" )
 JOIN "DBA"."t4" ON "DBA"."t3"."t3f1" = "DBA"."t4"."t4f2"
WHERE "DBA"."t4"."t4f3" = 'Нифигасебефамилия'

Но набирать хотим
Select t1.t1f2 where t1.t4f3='Нифигасебефамилия'
--ну или (если имена столбцов неуникальны)
Select t1.t1f2 where t1.(t4.t4f3='Нифигасебефамилия')

А остальное пущай ложиться на могучие плечи СУБД
15 дек 06, 08:21    [3539498]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
ЙОМОЙО
Guest
Не там скобку поставил
Select t1.t1f2 where t1.(t4.t4f3)='Нифигасебефамилия'
15 дек 06, 08:23    [3539503]     Ответить | Цитировать Сообщить модератору
 Re: О типах связей в сетевой модели данных.  [new]
vadiminfo
Member

Откуда: Обнинск
Сообщений: 4802
Александр Савинов
Любая теория проходит от начального творческого периода к времени, когда она превращается в догму и религию. И сейчас мы это наблюдаем на примере РМД.

А разве мы не видим, что других реальных теорий нет? ООМД - не является теоретически обоснованной. Это просто перенесение ООП в МД. Результат, несмотря на все казалось бы достоинства ООП (более естественное моделирование) - РМД устаяло, а ООМД пошло на спад. А ООП стали пытаться внедрять в РМД(ОРМД - расширение). Вот это уж точно мы видим.
А теории могут не только превращаться в догмы, но и переживать спады. Однако, это не значит, что им на смену должно прийти что попало, на основании лишь того, что это что попало еще не успело стать догмой или стереотипом. Хотя не очевидно, что ООП не имеет черт догм. Точнее оно имеет уже соответствующего типа сторонников.
15 дек 06, 08:55    [3539578]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 15 16 17 18 19 [20] 21 22 23 24 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить