powered by simpleCommunicator - 2.0.60     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / вопрос по парадигмам БД
25 сообщений из 79, страница 2 из 4
вопрос по парадигмам БД
    #33071778
Фотография XM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelR
сколько здесь парадигм?
сколько здесь онтологий?
сколько здесь болтологий???
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071804
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
И естественно, мы неизбежно приходим к вопросу о том, что такое "сущность". И тут можно встретить 2 точки зрения:
1. Бизнес-сущность. Что-то, существующее в предметной области, вполне различимое, известное и понятное специалистам/пользователям.
2. Сущность-факт. Что-то, о чем можно сделать запись в данной таблице БД.
В этой теме можно наблюдать обе точки зрения. При этом использование одного и того же термина "сущность" приводит стороны к недопониманию.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33071868
Фотография XM
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 mir
Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков?
А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :(
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072012
Фотография U-gene
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Насчет словаря. ИМХО лучше, чем это у нас не найти.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072081
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
mirИ естественно, мы неизбежно приходим к вопросу о том, что такое "сущность". И тут можно встретить 2 точки зрения:
1. Бизнес-сущность. Что-то, существующее в предметной области, вполне различимое, известное и понятное специалистам/пользователям.
2. Сущность-факт. Что-то, о чем можно сделать запись в данной таблице БД.
В этой теме можно наблюдать обе точки зрения. При этом использование одного и того же термина "сущность" приводит стороны к недопониманию.
Использование термина сущность для обозначения строки в таблице конечно неудачно. Сущность-факт, событие, сущность-связь других сущностей, как и сущность предмет - частные случаи сущности. Все они понятны бизнесу, только каждому по-своему . Вот дождь -это процесс или предмет? Нет, нет, не отвечайте плз., это не вопрос а иллюстрация. XM 2 mir
Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков?
А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :(
Лучше Дейта никто объяснять не умеет.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072320
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
SELECT
   a.[Account number],
   a.[Account name],
   a.[Open date],
   a.[Close date],
   b.[Actual date],
   b.[Account balance]
FROM
  Account a
  INNER JOIN
    Balance b
    ON
    a.[Account number] = b.[Account numer]
    AND
    b.[Actual date] = <Required date>

т.е. именно "сущность в определенный момент времени - строка". Иначе - "сущность - много строк".
ЗЫ Хотя, как я понимаю, все дело в интерпретации.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072374
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRИспользование термина сущность для обозначения строки в таблице конечно неудачно.Я тоже так считаю.
ModelRСущность-факт, событие, сущность-связь других сущностей, как и сущность предмет - частные случаи сущности.Точнее даже так: иногда запись в таблице соответствует бизнес-сущности (часный случай), но в общем случае информация о бизнес-сущности отображается на несколько записей в нескольких таблицах. Речь, разумеется, идет о РМД.
ModelRВсе они понятны бизнесу, только каждому по-своему.Полагаю, что "бизнесу" (т.е. пользователям) понятны исключительно бизнес-сущности, которые ему видны на внешнем уровне представления (по ANSI/SPARC). Всякие же "таблицы", "записи" и т.п. относятся к логическому уровню, который "бизнес" не видит и о котором часто даже не подозревает.[/quot]
ModelRВот дождь -это процесс или предмет? Нет, нет, не отвечайте плз., это не вопрос а иллюстрация.Мысль я не уловил, сорри.

XM 2 mir
Не подскажете [толковый] словарь стандарной терминологии (относительно БД), который не вызывал бы кривотолков?
А то, блин, часто доводится видеть различные пояснения одних терминов и (почти) идентичные пояснения различных терминов :(Сам бы такой хотел :) Собираешь всю жизнь с миру по нитке. Хороший источник "вразумления" - сайт Дейта и Паскаля http://www.dbdebunk.com. Но там все не систематизировано.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072415
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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.
SELECT
   a.[Account number],
   a.[Account name],
   a.[Open date],
   a.[Close date],
   b.[Actual date],
   b.[Account balance]
FROM
  Account a
  INNER JOIN
    Balance b
    ON
    a.[Account number] = b.[Account numer]
    AND
    b.[Actual date] = <Required date>

т.е. именно "сущность в определенный момент времени - строка". Иначе - "сущность - много строк".
ЗЫ Хотя, как я понимаю, все дело в интерпретации.В чем прикол? Таблиц ведь у вас две не случайно: логически сущностей тоже две
Счет(Номер,Наименование,ДатаОткрытия,ДатаЗакрытия) и
ОстатокСчета(Номер,Дата,Сумма)
и связь Каждый Счет имеет несколько ОстатокСчета.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072690
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Вот это и есть та самая интерпретация, о которой я говорил.

Логически - как раз-таки одна сущность.
Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто.

Тест простой:
-- Существует счет без остатка?
-- Существует ли остаток без счета?
Т.е. налицо композиция (в терминах ООП)

ЗЫ Чтобы понятия развести:
-- есть связи (1-М, М-М), которые применимы к парам " естественная сущность (объект реального мира) - естественная сущность (объект реального мира)", т.е. воспроизводят парадигму, по словам автора треда, "сущность-запись"

-- есть связи (1-М, М-М), которые применимы к парам " естественная сущность (объект реального мира) - суррогатная сущность (суррогатный объект, созданый для хранения атрибутов естественной сущности), т.е. то, что чаще всего и характерно для МДМ схем.

Несмотря на внешнюю схожесть это - разные вещи, что и сбивает с толку, наверное.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072707
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Извините, поправка:

-- есть связи (1-М), которые применимы к парам " естественная сущность (объект реального мира) - суррогатная сущность (суррогатный объект, созданый для хранения атрибутов естественной сущности), т.е. то, что чаще всего и характерно для МДМ схем
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072808
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JimmyЛогически - как раз-таки одна сущность.
Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто.
Я и говорю - вопрос в терминологии. Соотношение "одна бизнес-сущность - одна строка в таблице" - имеет максимальные шансы быть нарушенным, с этим трудно спорить, да и незачем.

Если мы помним, что физическая и логическая модели не обязаны соответствовать одна другой - конфликта не остается. У нас есть логическая модель с бизнес-сущностями, у нас есть физическая модель с таблицами (которые, если не ошибаюсь, Кодд и называл сущностями). В логической модели - если нам удобно так думать, давайте нарисуем счет с таблицей остатков. В Oracle Designer, кстати, для этого было очень удобное средство: можно было вкладывать сущности одна в другую. А потом появились nested tables, что дает "один в один" воспроизвести это отношение на физическом уровне.

Обсуждать, насколько далеко это от изначального утверждения автора - имхо бессмысленно. Ограничусь утверждением, что для "кубических" задач фактом будет именно "остаток по счету.. на дату.. равен..". Не потому что мы его натянуто выделили, а объективно - по смыслу решаемых задач.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33072848
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 softwarer

Я согласен с каждым Вашим словом :0))

Просто, видимо формулировать парадигмы нужно было несколько иначе,в контексте решаемых задач, т.е:

-- БД для регистрации транзакций (OLTP системы, 3-4 НФ)
-- БД для получения отчетов (OLAP в том числе, "звезда", "снежинка")
-- БД - универсальное "хранилище" ("объектная" надстройка над РСУБД)

2 Илья(Phantom)
Мне кажется, что такая классификация более соответствует практическим целям, нежели предложенная Вами.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073117
Лучше бы Вы, Jimmy, для начала, закрыли глаза на реляционную модель...
В Вашем примере можно увидеть две "естественные", как Вы выразились, сущности - Счет и День. И связь между ними

Счет - Имеет остаток на/За который имеется остаток по - День

с характеристикой связи "Остаток". И ничего здесь не натянуто даже с точки зрения бизнеса...

Павел Воронцов: "... при этом отношение сущность - строка таблицы как правило нарушается". Не нарушается это "отношение" в результате нормализации (сущность - это все, что может быть идентифицировано, а кортеж, хотя и не эффективно, но может быть "идентифицирован", и можно "безнаказанно" утверждать, что он представляет некоторую, возможно не выявленную в начале на концептуальном уровне, сущность). Может быть речь идет о представлении в РМД связей М:М ? В этом случае соответствующее отношение представляет связь между сущностями. Либо сущность, либо связь между сущностями. Вы, Илья, про связи "забыли" в п.1...

"Парадигмы отражения", видимо, следует различать по механизмам идентификации сущностей, механизмам представления связей между сущностями и возможностям прямого доступа к сущностям (которого может не быть, например, если "сущность" "встроена" в другую "сущность")...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073326
ModelR
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
JimmyЛогически - как раз-таки одна сущность.
Выделение сущности "остаток на счете" с точки зрения проектировщика оправдано, конечно, но с точки зрения бизнеса - несколько натянуто.
Не согласен. Каковы бизнес правила в данном случае?
(1) Каждый счет имеет единственное Наименование
(2) Каждый счет имеет один или несколько Остатков.
как иначе их выразить не вводя понятие Остаток?
Я не говорю, что этот язык абсолютно понятен бизнесу, однако это то минимальное общее понятийное поле, на котором проектировщик может надеятся найти общий язык с бизнесом на этапе проекта.
softwarer
Если мы помним, что физическая и логическая модели не обязаны соответствовать одна другой - конфликта не остается. У нас есть логическая модель с бизнес-сущностями, у нас есть физическая модель с таблицами (которые, если не ошибаюсь, Кодд и называл сущностями). В логической модели - если нам удобно так думать, давайте нарисуем счет с таблицей остатков. В Oracle Designer, кстати, для этого было очень удобное средство: можно было вкладывать сущности одна в другую. А потом появились nested tables, что дает "один в один" воспроизвести это отношение на физическом уровне.
Уточнение. В Oracle Designer вложение А в Б означало "Каждое А есть Б" в смысле состава атрибутов, т.е. скорее это было наследование.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073338
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Илья(Phantom)
Пишу статью-обзор по используемым парадигмам отражения логических сущностей в приложениях на БД.


Все-таки разнообразие взглядов и терминов на приложения БД все еще спосбно впечатлять.
Термин парадигма прижился в технология программирования, но еще, вроде, не пробил себе дорогу в приложениях БД. Под логическими сущностями, наверное, понимаются средства структурирования данных и противопоставляются не логическим - сущностям реалного мира. И они типа разные у разных моделей данных. И их надо отображать как это происходит при трансляции модели данных ER в РМД. Тада может лучше спользовать терми "Категория"? В том смысле, что каждой модели свои категории. В, конце концов, в математике есть теория категорий, которая занимается как раз отображениями. Я не призываю ее использовать, а говорю о смозвучности. Кроме того, термин онтология заимствован, наверное, из философии, и возможно, категория там с онтологией хорошо, уживаются. Но в любом случае есть модели, которые использут термин сущность и есть которые не используют. И не известно существует этот термин, только благодаря некотром моделям данных, или его природа выходит за рамки этих моделей.

Илья(Phantom)
Если угодно Логическая сущность = объект. Но это немного шире чем просто объект.


Объекты тоже используют и в смысле обектов реального мира, и в смысле средств структурирования данных. Т.е. тада вторые тоже могут быть логическими? Сложность в том, что уже используются термины концептуальные и физические в одном ряду с логическими. И как правило, например, концептуальные отображаются в логические, а последние в физические. Реже наоборот и на одном уровне. Хотя считается некоторыми авторами, что иерархические можно отобразить в реляционные.
Я намекаю, на то что прилогательное "логические", возможно лучше выкинуть, а за одно и термины "парадигму" и "онтология" тоже претендуют на удаление из статьи про приложения БД.

Ну возможно, что объект в ООП уже сущности в ER, потому что строго идентифицирован и имеет дополнительные возможности - поведение. Т.е. больше признаков как у понятия.

Илья(Phantom)
В основном работы по онтологиям и экспертным системам В.Л.Стефанюка.


Зкспертные системы все же предполагают не приложения БД, а приложения БЗ (Баз знаний). Там, скорее всего, все сложнее и тока сущностиями, хотя и логическими, не отделаться.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073443
Фотография ChA
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoЯ намекаю, на то что прилогательное "логические", возможно лучше выкинуть, а за одно и термины "парадигму" и "онтология" тоже претендуют на удаление из статьи про приложения БД.А чем же тогда поразить вероятного читателя статьи ? Дабы увидев эти слова, просветлился и понял, что не лох какой писал, а человек ученый...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073503
mir
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну, с термином "парадигма" не все так плохо. Это просто *концепция*, *модель постановки проблем и их решения*. Термин часто применяется для большего наукообразия.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073825
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
2 Андрей Леонидович
Лучше бы Вы, Jimmy, для начала, закрыли глаза на реляционную модель...
В Вашем примере можно увидеть две "естественные", как Вы выразились, сущности - Счет и День. И связь между ними

Счет - Имеет остаток на/За который имеется остаток по - День

с характеристикой связи "Остаток". И ничего здесь не натянуто даже с точки зрения бизнеса...


0. Насчет закрытия глаз на реляционную модель - не понял, извините.
1. Рекомендую взглянуть, к примеру, на документ/форму/отчет "Выписка по счету", "Баланс" и т.п. Любой из этих документов, столь любимых бухгалтерами - срез состояния счета/ов на определенную дату.
3. И, еще раз повторюсь, специально для Вас: "Хотя, как я понимаю, все дело в интерпретации" (с) Jimmy.
Т.е. можно привести массу аргументов в пользу любой модели, и все они будут достаточно разумными (равно как и массу контрагрументов).
4. Тем не менее, смею утверждать, что нельзя смешивать концепции проектирования OLTP систем и DSS систем, т.к. они решают разные задачи, и вот контекст этих задач имеет смысл назвать "парадигмой" или как-то еще.
Ни больше - ни меньше.
5. Исходя из п.3 думаю флейм нужно прекратить.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33073944
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ModelRУточнение. В Oracle Designer вложение А в Б означало "Каждое А есть Б" в смысле состава атрибутов, т.е. скорее это было наследование.
Хм. Боюсь, я лет шесть им не пользовался; за это время что-то могло поменяться, да и я могу ошибиться.

Что есть "означало"? Насколько я помню, я применял это для "технических детальных таблиц", например - мог вложить в клиента таблицу "телефонные номера клиента", привязанную к клиенту по FK, многие к одному, и не имеющую других ссылок. По этой ER-ке генерилась нормальная (ожидаемая мной) структура таблиц. Наследованием такое вроде бы не является :) Хотя не исключаю, что я по неведению использовал фичу не так, как предполагали разработчики. Но было весьма удобно :)
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33074402
Уважаемый Jimmy !

0. "Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели." Вот откуда взялось "закрытие глаз".
1. Ну зачем же "сопоставлять" представление сущностей в БД и представление отчетов пользователям ? Хотя в идеале, конечно, эти представления могли бы совпадать.
3. Все дело, скорее, в сути, а не в интерпретации.
4. Существуют прикладные системы, в которых OLTP и DSS работают на одной БД. Можно, и даже нужно, "смешивать концепции".
5. Исходя из п.3 флейм может и нужно прекратить, но не путь к истине. Наверное ?..
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33074473
Фотография Jimmy
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Закроем глаза на "куб" и вообще любую многомерную структуру, кроме реляционной модели." Вот откуда взялось "закрытие глаз".

Весьма странный вывод. Структура куба (MOLAP) - вещь далекая от РСУБД. И рассуждать о его устройстве - дело неблагодарное, в рамках данной темы, во всяком случае.
Или, я просто не уловил Вашу логику?

Существуют прикладные системы, в которых OLTP и DSS работают на одной БД. Можно, и даже нужно, "смешивать концепции

ОК, по простому скажу:
1. "Звезду" можно свести к одной таблице (сущности?), денормализованной до 1НФ, при этом DSS система будет работать . Т.е. процессы получения необходимых отчетов и/или формирования куба не пострадают, а может даже ускоряться.

2. OLTP схему, в принципе, тоже можно свести к одной мега-таблице (сущности?). При этом... будет "абзац" системе. Свою функцию она выполнять не сможет .

Это, по вашему, одна и таже концепция (или парадигма?) проектирования? Что-ж, не буду разубеждать.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33075557
1. Да, Вы не уловили мою логику. Вы предложили закрыть глаза на одно, а я Вам - на другое. Это была ирония, конечно - не нужно ни на что закрывать глаза...
2. Если проектируемая БД предназначена для решения и тех, и других задач, то те "концепции проектирования", о которых Вы говорили, конечно "смешиваются". При чем здесь "сведение к одной таблице" ???
У Вас должна быть хорошо нормализованная, и, одновременно, хорошо денормализованная ОДНА БД...

Поскольку автор темы ей уже не интересуется, и не захотел четче сформулировать "проблему" (обиделся, вроде как, непонятно на что), то и обсуждать нечего...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33075612
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> обсуждать нечего...

Отчего же? Очень даже есть чего.

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

Imho member ModelR в [1550920] был к ответу на исходный вопрос ближе всего.
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33075679
Нет, guest_20040621. ModelR тоже предложил (ДВАЖДЫ в упомянутом Вами сообщении !) "не вдаваться в вопросы" (чем это отличается от "закрывать глаза" ?). Он может быть образнее других указал автору на не четкую формулировку "проблемы". Это да...
...
Рейтинг: 0 / 0
вопрос по парадигмам БД
    #33075711
Илья(Phantom), если Вы еще "здесь".
Конкретные примеры схем БД для 2 и 3 на логическом уровне ничем не отличаются от аналогичных схем для 1. Надеюсь "товарищи на заграничных форумах" Вам уже объяснили, что:

1) в ООСУБД связи многие-ко-многим на логическом уровне представляются так же, как и в "Р"СУБД;
2) встраивание объектов осложняет (мягко говоря) доступ к встроенным объектам (сущностям), и, опять же, реализовано и в большинстве "Р"СУБД (то бишь теперь - О"Р"СУБД)...
...
Рейтинг: 0 / 0
25 сообщений из 79, страница 2 из 4
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / вопрос по парадигмам БД
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]