Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
ModelR сколько здесь парадигм? сколько здесь онтологий? сколько здесь болтологий??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 12:48 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
И естественно, мы неизбежно приходим к вопросу о том, что такое "сущность". И тут можно встретить 2 точки зрения: 1. Бизнес-сущность. Что-то, существующее в предметной области, вполне различимое, известное и понятное специалистам/пользователям. 2. Сущность-факт. Что-то, о чем можно сделать запись в данной таблице БД. В этой теме можно наблюдать обе точки зрения. При этом использование одного и того же термина "сущность" приводит стороны к недопониманию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 12:56 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 mir Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков? А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :( ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 13:10 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Насчет словаря. ИМХО лучше, чем это у нас не найти. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 13:45 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
mirИ естественно, мы неизбежно приходим к вопросу о том, что такое "сущность". И тут можно встретить 2 точки зрения: 1. Бизнес-сущность. Что-то, существующее в предметной области, вполне различимое, известное и понятное специалистам/пользователям. 2. Сущность-факт. Что-то, о чем можно сделать запись в данной таблице БД. В этой теме можно наблюдать обе точки зрения. При этом использование одного и того же термина "сущность" приводит стороны к недопониманию. Использование термина сущность для обозначения строки в таблице конечно неудачно. Сущность-факт, событие, сущность-связь других сущностей, как и сущность предмет - частные случаи сущности. Все они понятны бизнесу, только каждому по-своему . Вот дождь -это процесс или предмет? Нет, нет, не отвечайте плз., это не вопрос а иллюстрация. XM 2 mir Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков? А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :( Лучше Дейта никто объяснять не умеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 14:00 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
softwarer Jimmy есть и другие отличия, типа истории изменения значения атрибута, которая хранится в таблице фактов. Тут, пожалуй, околотерминологическое расхождение. Сущностью в MDM-cхеме в общем случае является "факт", именно что одна строка в таблице. В ранее упомянутом кубе покупок - факт покупки, то, что Вы назвали "сущностью в определенный момент времени". Время - или другой "исторический" разрез - является одним из измерений этого куба. С тем же успехом можно рассматривать не временной аспект, а например географический - сущность вроде бы одна, но продаж по Москве больше, чем по Питеру. Разумеется, с логической точки зрения можно сказать, что таким срезом куба описывается некая "сущность реального мира". Но здесь с моей точки зрения как раз один из тех случаев, когда в проектировании уходят от однозначного соответствия реальных объектов сущностям проекта. Да, в реальном мире есть такая сущность. А в нашем проекте мы мыслим несколько другими. У этих других может быть прямой аналог в реальном мире - как у продаж, а может и не быть. Разумеется, в любой практической схеме будут исключения. Например, факт "замена" может быть выражен не только строкой в таблице "замен", но также строками в таблицах "покупка" - "возврат" - "покупка", если это отчего-то удобнее. История как контрпример принципа "одна строка - одна сущность" опять-таки видна скорее в таблицах измерений, во всяких SCD2. Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели. Возьмем упрощенную модель: Сущность "Лицевой Счет" -- Номер счета - атр. -- Наименование счета - атр. -- Остаток на счете - атр. /* Существенная характеристика,изменяется во времени, т.е существует серия значений: --- (на 01.01.2005) --- (на 02.01.2005) --- (на 03.01.2005) --- (на 04.01.2005) --- (на 05.01.2005) --- (на 06.01.2005) ::: */ -- Дата открытия - атр. -- Дата закрытия - атр. Таблицы: - Account -- Account number (PK) -- Account name -- Open date -- Close date - Balance -- Account number(PK)(FK Account) -- Actual date(PK) -- Account balance Таким образом, "сущность - строка" описывается следующим запросом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. т.е. именно "сущность в определенный момент времени - строка". Иначе - "сущность - много строк". ЗЫ Хотя, как я понимаю, все дело в интерпретации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 14:54 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
ModelRИспользование термина сущность для обозначения строки в таблице конечно неудачно.Я тоже так считаю. ModelRСущность-факт, событие, сущность-связь других сущностей, как и сущность предмет - частные случаи сущности.Точнее даже так: иногда запись в таблице соответствует бизнес-сущности (часный случай), но в общем случае информация о бизнес-сущности отображается на несколько записей в нескольких таблицах. Речь, разумеется, идет о РМД. ModelRВсе они понятны бизнесу, только каждому по-своему.Полагаю, что "бизнесу" (т.е. пользователям) понятны исключительно бизнес-сущности, которые ему видны на внешнем уровне представления (по ANSI/SPARC). Всякие же "таблицы", "записи" и т.п. относятся к логическому уровню, который "бизнес" не видит и о котором часто даже не подозревает.[/quot] ModelRВот дождь -это процесс или предмет? Нет, нет, не отвечайте плз., это не вопрос а иллюстрация.Мысль я не уловил, сорри. XM 2 mir Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков? А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :(Сам бы такой хотел :) Собираешь всю жизнь с миру по нитке. Хороший источник "вразумления" - сайт Дейта и Паскаля http://www.dbdebunk.com. Но там все не систематизировано. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 15:07 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Jimmy Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели. Возьмем упрощенную модель: Сущность "Лицевой Счет" -- Номер счета - атр. -- Наименование счета - атр. -- Остаток на счете - атр. /* Существенная характеристика,изменяется во времени, т.е существует серия значений: --- (на 01.01.2005) --- (на 02.01.2005) --- (на 03.01.2005) --- (на 04.01.2005) --- (на 05.01.2005) --- (на 06.01.2005) ::: */ -- Дата открытия - атр. -- Дата закрытия - атр. Таблицы: - Account -- Account number (PK) -- Account name -- Open date -- Close date - Balance -- Account number(PK)(FK Account) -- Actual date(PK) -- Account balance Таким образом, "сущность - строка" описывается следующим запросом: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. т.е. именно "сущность в определенный момент времени - строка". Иначе - "сущность - много строк". ЗЫ Хотя, как я понимаю, все дело в интерпретации.В чем прикол? Таблиц ведь у вас две не случайно: логически сущностей тоже две Счет(Номер,Наименование,ДатаОткрытия,ДатаЗакрытия) и ОстатокСчета(Номер,Дата,Сумма) и связь Каждый Счет имеет несколько ОстатокСчета. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 15:15 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Вот это и есть та самая интерпретация, о которой я говорил. Логически - как раз-таки одна сущность. Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто. Тест простой: -- Существует счет без остатка? -- Существует ли остаток без счета? Т.е. налицо композиция (в терминах ООП) ЗЫ Чтобы понятия развести: -- есть связи (1-М, М-М), которые применимы к парам " естественная сущность (объект реального мира) - естественная сущность (объект реального мира)", т.е. воспроизводят парадигму, по словам автора треда, "сущность-запись" -- есть связи (1-М, М-М), которые применимы к парам " естественная сущность (объект реального мира) - суррогатная сущность (суррогатный объект, созданый для хранения атрибутов естественной сущности), т.е. то, что чаще всего и характерно для МДМ схем. Несмотря на внешнюю схожесть это - разные вещи, что и сбивает с толку, наверное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 16:32 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Извините, поправка: -- есть связи (1-М), которые применимы к парам " естественная сущность (объект реального мира) - суррогатная сущность (суррогатный объект, созданый для хранения атрибутов естественной сущности), т.е. то, что чаще всего и характерно для МДМ схем ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 16:36 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
JimmyЛогически - как раз-таки одна сущность. Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто. Я и говорю - вопрос в терминологии. Соотношение "одна бизнес-сущность - одна строка в таблице" - имеет максимальные шансы быть нарушенным, с этим трудно спорить, да и незачем. Если мы помним, что физическая и логическая модели не обязаны соответствовать одна другой - конфликта не остается. У нас есть логическая модель с бизнес-сущностями, у нас есть физическая модель с таблицами (которые, если не ошибаюсь, Кодд и называл сущностями). В логической модели - если нам удобно так думать, давайте нарисуем счет с таблицей остатков. В Oracle Designer, кстати, для этого было очень удобное средство: можно было вкладывать сущности одна в другую. А потом появились nested tables, что дает "один в один" воспроизвести это отношение на физическом уровне. Обсуждать, насколько далеко это от изначального утверждения автора - имхо бессмысленно. Ограничусь утверждением, что для "кубических" задач фактом будет именно "остаток по счету.. на дату.. равен..". Не потому что мы его натянуто выделили, а объективно - по смыслу решаемых задач. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 17:08 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 softwarer Я согласен с каждым Вашим словом :0)) Просто, видимо формулировать парадигмы нужно было несколько иначе,в контексте решаемых задач, т.е: -- БД для регистрации транзакций (OLTP системы, 3-4 НФ) -- БД для получения отчетов (OLAP в том числе, "звезда", "снежинка") -- БД - универсальное "хранилище" ("объектная" надстройка над РСУБД) 2 Илья(Phantom) Мне кажется, что такая классификация более соответствует практическим целям, нежели предложенная Вами. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 17:17 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Лучше бы Вы, Jimmy, для начала, закрыли глаза на реляционную модель... В Вашем примере можно увидеть две "естественные", как Вы выразились, сущности - Счет и День. И связь между ними Счет - Имеет остаток на/За который имеется остаток по - День с характеристикой связи "Остаток". И ничего здесь не натянуто даже с точки зрения бизнеса... Павел Воронцов: "... при этом отношение сущность - строка таблицы как правило нарушается". Не нарушается это "отношение" в результате нормализации (сущность - это все, что может быть идентифицировано, а кортеж, хотя и не эффективно, но может быть "идентифицирован", и можно "безнаказанно" утверждать, что он представляет некоторую, возможно не выявленную в начале на концептуальном уровне, сущность). Может быть речь идет о представлении в РМД связей М:М ? В этом случае соответствующее отношение представляет связь между сущностями. Либо сущность, либо связь между сущностями. Вы, Илья, про связи "забыли" в п.1... "Парадигмы отражения", видимо, следует различать по механизмам идентификации сущностей, механизмам представления связей между сущностями и возможностям прямого доступа к сущностям (которого может не быть, например, если "сущность" "встроена" в другую "сущность")... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 18:50 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
JimmyЛогически - как раз-таки одна сущность. Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто. Не согласен. Каковы бизнес правила в данном случае? (1) Каждый счет имеет единственное Наименование (2) Каждый счет имеет один или несколько Остатков. как иначе их выразить не вводя понятие Остаток? Я не говорю, что этот язык абсолютно понятен бизнесу, однако это то минимальное общее понятийное поле, на котором проектировщик может надеятся найти общий язык с бизнесом на этапе проекта. softwarer Если мы помним, что физическая и логическая модели не обязаны соответствовать одна другой - конфликта не остается. У нас есть логическая модель с бизнес-сущностями, у нас есть физическая модель с таблицами (которые, если не ошибаюсь, Кодд и называл сущностями). В логической модели - если нам удобно так думать, давайте нарисуем счет с таблицей остатков. В Oracle Designer, кстати, для этого было очень удобное средство: можно было вкладывать сущности одна в другую. А потом появились nested tables, что дает "один в один" воспроизвести это отношение на физическом уровне. Уточнение. В Oracle Designer вложение А в Б означало "Каждое А есть Б" в смысле состава атрибутов, т.е. скорее это было наследование. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 21:55 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom) Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД. Все-таки разнообразие взглядов и терминов на приложения БД все еще спосбно впечатлять. Термин парадигма прижился в технология программирования, но еще, вроде, не пробил себе дорогу в приложениях БД. Под логическими сущностями, наверное, понимаются средства структурирования данных и противопоставляются не логическим - сущностям реалного мира. И они типа разные у разных моделей данных. И их надо отображать как это происходит при трансляции модели данных ER в РМД. Тада может лучше спользовать терми "Категория"? В том смысле, что каждой модели свои категории. В, конце концов, в математике есть теория категорий, которая занимается как раз отображениями. Я не призываю ее использовать, а говорю о смозвучности. Кроме того, термин онтология заимствован, наверное, из философии, и возможно, категория там с онтологией хорошо, уживаются. Но в любом случае есть модели, которые использут термин сущность и есть которые не используют. И не известно существует этот термин, только благодаря некотром моделям данных, или его природа выходит за рамки этих моделей. Илья(Phantom) Если угодно Логическая сущность = объект. Но это немного шире чем просто объект. Объекты тоже используют и в смысле обектов реального мира, и в смысле средств структурирования данных. Т.е. тада вторые тоже могут быть логическими? Сложность в том, что уже используются термины концептуальные и физические в одном ряду с логическими. И как правило, например, концептуальные отображаются в логические, а последние в физические. Реже наоборот и на одном уровне. Хотя считается некоторыми авторами, что иерархические можно отобразить в реляционные. Я намекаю, на то что прилогательное "логические", возможно лучше выкинуть, а за одно и термины "парадигму" и "онтология" тоже претендуют на удаление из статьи про приложения БД. Ну возможно, что объект в ООП уже сущности в ER, потому что строго идентифицирован и имеет дополнительные возможности - поведение. Т.е. больше признаков как у понятия. Илья(Phantom) В основном работы по онтологиям и экспертным системам В.Л.Стефанюка. Зкспертные системы все же предполагают не приложения БД, а приложения БЗ (Баз знаний). Там, скорее всего, все сложнее и тока сущностиями, хотя и логическими, не отделаться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.05.2005, 22:10 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
vadiminfoЯ намекаю, на то что прилогательное "логические", возможно лучше выкинуть, а за одно и термины "парадигму" и "онтология" тоже претендуют на удаление из статьи про приложения БД.А чем же тогда поразить вероятного читателя статьи ? Дабы увидев эти слова, просветлился и понял, что не лох какой писал, а человек ученый... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 01:10 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Ну, с термином "парадигма" не все так плохо. Это просто *концепция*, *модель постановки проблем и их решения*. Термин часто применяется для большего наукообразия. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 06:36 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
2 Андрей Леонидович Лучше бы Вы, Jimmy, для начала, закрыли глаза на реляционную модель... В Вашем примере можно увидеть две "естественные", как Вы выразились, сущности - Счет и День. И связь между ними Счет - Имеет остаток на/За который имеется остаток по - День с характеристикой связи "Остаток". И ничего здесь не натянуто даже с точки зрения бизнеса... 0. Насчет закрытия глаз на реляционную модель - не понял, извините. 1. Рекомендую взглянуть, к примеру, на документ/форму/отчет "Выписка по счету", "Баланс" и т.п. Любой из этих документов, столь любимых бухгалтерами - срез состояния счета/ов на определенную дату. 3. И, еще раз повторюсь, специально для Вас: "Хотя, как я понимаю, все дело в интерпретации" (с) Jimmy. Т.е. можно привести массу аргументов в пользу любой модели, и все они будут достаточно разумными (равно как и массу контрагрументов). 4. Тем не менее, смею утверждать, что нельзя смешивать концепции проектирования OLTP систем и DSS систем, т.к. они решают разные задачи, и вот контекст этих задач имеет смысл назвать "парадигмой" или как-то еще. Ни больше - ни меньше. 5. Исходя из п.3 думаю флейм нужно прекратить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 10:18 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
ModelRУточнение. В Oracle Designer вложение А в Б означало "Каждое А есть Б" в смысле состава атрибутов, т.е. скорее это было наследование. Хм. Боюсь, я лет шесть им не пользовался; за это время что-то могло поменяться, да и я могу ошибиться. Что есть "означало"? Насколько я помню, я применял это для "технических детальных таблиц", например - мог вложить в клиента таблицу "телефонные номера клиента", привязанную к клиенту по FK, многие к одному, и не имеющую других ссылок. По этой ER-ке генерилась нормальная (ожидаемая мной) структура таблиц. Наследованием такое вроде бы не является :) Хотя не исключаю, что я по неведению использовал фичу не так, как предполагали разработчики. Но было весьма удобно :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 10:56 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Уважаемый Jimmy ! 0. "Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели." Вот откуда взялось "закрытие глаз". 1. Ну зачем же "сопоставлять" представление сущностей в БД и представление отчетов пользователям ? Хотя в идеале, конечно, эти представления могли бы совпадать. 3. Все дело, скорее, в сути, а не в интерпретации. 4. Существуют прикладные системы, в которых OLTP и DSS работают на одной БД. Можно, и даже нужно, "смешивать концепции". 5. Исходя из п.3 флейм может и нужно прекратить, но не путь к истине. Наверное ?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 13:03 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели." Вот откуда взялось "закрытие глаз". Весьма странный вывод. Структура куба (MOLAP) - вещь далекая от РСУБД. И рассуждать о его устройстве - дело неблагодарное, в рамках данной темы, во всяком случае. Или, я просто не уловил Вашу логику? Существуют прикладные системы, в которых OLTP и DSS работают на одной БД. Можно, и даже нужно, "смешивать концепции ОК, по простому скажу: 1. "Звезду" можно свести к одной таблице (сущности?), денормализованной до 1НФ, при этом DSS система будет работать . Т.е. процессы получения необходимых отчетов и/или формирования куба не пострадают, а может даже ускоряться. 2. OLTP схему, в принципе, тоже можно свести к одной мега-таблице (сущности?). При этом... будет "абзац" системе. Свою функцию она выполнять не сможет . Это, по вашему, одна и таже концепция (или парадигма?) проектирования? Что-ж, не буду разубеждать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 13:18 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
1. Да, Вы не уловили мою логику. Вы предложили закрыть глаза на одно, а я Вам - на другое. Это была ирония, конечно - не нужно ни на что закрывать глаза... 2. Если проектируемая БД предназначена для решения и тех, и других задач, то те "концепции проектирования", о которых Вы говорили, конечно "смешиваются". При чем здесь "сведение к одной таблице" ??? У Вас должна быть хорошо нормализованная, и, одновременно, хорошо денормализованная ОДНА БД... Поскольку автор темы ей уже не интересуется, и не захотел четче сформулировать "проблему" (обиделся, вроде как, непонятно на что), то и обсуждать нечего... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 17:56 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
> обсуждать нечего... Отчего же? Очень даже есть чего. Что абсолютно непонятно: на каком основании некоторые из участвующих в обсуждении взяли один класс задач и ограничили концепции проектирования применительно исключительно к этим задачам. На мой взгляд, частные случаи никогда ничего не доказывали. Imho member ModelR в [1550920] был к ответу на исходный вопрос ближе всего. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 18:17 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Нет, guest_20040621. ModelR тоже предложил (ДВАЖДЫ в упомянутом Вами сообщении !) "не вдаваться в вопросы" (чем это отличается от "закрывать глаза" ?). Он может быть образнее других указал автору на не четкую формулировку "проблемы". Это да... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 18:54 |
|
||
|
вопрос по парадигмам БД
|
|||
|---|---|---|---|
|
#18+
Илья(Phantom), если Вы еще "здесь". Конкретные примеры схем БД для 2 и 3 на логическом уровне ничем не отличаются от аналогичных схем для 1. Надеюсь "товарищи на заграничных форумах" Вам уже объяснили, что: 1) в ООСУБД связи многие-ко-многим на логическом уровне представляются так же, как и в "Р"СУБД; 2) встраивание объектов осложняет (мягко говоря) доступ к встроенным объектам (сущностям), и, опять же, реализовано и в большинстве "Р"СУБД (то бишь теперь - О"Р"СУБД)... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2005, 19:15 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=33073825&tid=1545856]: |
0ms |
get settings: |
7ms |
get forum list: |
15ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
72ms |
get topic data: |
13ms |
get forum data: |
4ms |
get page messages: |
99ms |
get tp. blocked users: |
2ms |
| others: | 242ms |
| total: | 458ms |

| 0 / 0 |
