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

← →
StriderMan © (2006-11-10 09:57) [0]

Доброго времени, мастера!

Не знал как правильно назвать ветку, поэтому сабж.
Заинтересовал меня перенос некоторых понятий ООП на построение баз данных. Для начала наследование.
Обратимся к класическому примеру из всех книжек с разделом "ООП".
Допустим есть таблица "Автомобили", обладающая определенным набором полей. Также есть понятия "Легковые автомобили", "Грузовые автомобили" и т.п, обладающие своими собственными свойствами, дополняющими поля таблицы "Автомобили".
Как построить структуру такой БД в принципе понятно, но будет ли это корректно с точки зрения основ построения БД? Есть ли какие-то исследования и методики для решения подобных задач? Что почитать посоветуете чтоб не городить велосипед?

← →
Курдль © (2006-11-10 10:00) [1]

> Как построить структуру такой БД в принципе понятно, но
> будет ли это корректно с точки зрения основ построения БД?

Это будет совершенно правильно со всех точек зрения.
Реляционные СУБД не вчера придуманы. И ER-диаграммы не вчера.
А в последних не просто так предусмотрены связи Inheritance, причем с разными вариантами типа Mutually exclusive/inclusive children.

← →
ЮЮ © (2006-11-10 10:01) [2]

> но будет ли это корректно с точки зрения основ построения БД?

И какие основы ты попираешь?

← →
ЮЮ © (2006-11-10 10:03) [3]

> А в последних не просто так предусмотрены связи Inheritance,
> причем с разными вариантами типа Mutually exclusive/inclusive
> children.

А это при чем? Или я не понял, то что в "Как построить структуру такой БД в принципе понятно"?

← →
Anatoly Podgoretsky © (2006-11-10 10:08) [4]

> StriderMan (10.11.2006 09:57:00) [0]

ООП оно ни к чему не привязано, даже буква П лишняя, это биология, зоология и ботаника, притянутые к П

← →
Курдль © (2006-11-10 10:08) [5]

> ЮЮ © (10.11.06 10:03) [3]
> А это при чем? Или я не понял, то что в "Как построить структуру
> такой БД в принципе понятно"?

Я просто о том, что инструментарий того самого построения БД (CASE-инструментарий) давно заточен под создание реляционных БД с наследственными связями. Они позволяют использовать разные типы наследования, навроде тех, что я указал а также наследовать все поля, либо только ключевые.

← →
StriderMan © (2006-11-10 10:12) [6]

> Anatoly Podgoretsky © (10.11.06 10:08) [4]
> ООП оно ни к чему не привязано, даже буква П лишняя

если "П" рассматривать как Построение или Подход то все встает на свои места.

Вобщем вопрос остался один: Что почитать?

ну и еще один назрел: я работаю в основном с FB, если там какие специальные фичи для сабжа?, в книжке че-т не углядел.
Сейчас реализую наследование оч. просто: наследная таблица хранит ID родительской, и под наследников создаю вьюхи.

← →
Курдль © (2006-11-10 10:16) [7]

> StriderMan © (10.11.06 10:12) [6]
> ну и еще один назрел: я работаю в основном с FB, если там
> какие специальные фичи для сабжа?, в книжке че-т не углядел.
>
> Сейчас реализую наследование оч. просто: наследная таблица
> хранит ID родительской, и под наследников создаю вьюхи.

Никаких специфических "фич для сабжа" не существует. РСУБД на физическом уровне принимает наследование потомок-родитель, как обычную реляционную связь много-к-одному.
Книжек по этому вопросу тоже нет - достаточно иметь просто здравый смысл.
Если Вам хватило здравого смысла разглядеть наследственные отношения у разнотипных автомобилей, то Вы определите их и в других областях (например, физических и юридических лиц, разнообразных документов и т.п.).

← →
tesseract © (2006-11-10 10:21) [8]

> Книжек по этому вопросу тоже нет - достаточно иметь просто
> здравый смысл.

Сорцы PostgresQL ИМХО тоже сойдут.

> ну и еще один назрел: я работаю в основном с FB, если там
> какие специальные фичи для сабжа?

Нет переходи на postgress. Там есть фичи даже для древовидных структур.

← →
Anatoly Podgoretsky © (2006-11-10 10:22) [9]

> StriderMan (10.11.2006 10:12:06) [6]

Если расматривать так, то да, но вообще то П это П

← →
StriderMan © (2006-11-10 10:23) [10]

> Если Вам хватило здравого смысла разглядеть наследственные
> отношения у разнотипных автомобилей, то Вы определите их
> и в других областях (например, физических и юридических
> лиц, разнообразных документов и т.п.).

спасибо, "с горем пополам" это я вижу.

> связь много-к-одному.

немного не въехал, я понимал эту связь как один-к-одному. Т.е. "на пальцах" под каждую запись "наследника" существует запись в родительской таблице

← →
Курдль © (2006-11-10 10:27) [11]

> StriderMan © (10.11.06 10:23) [10]
> немного не въехал, я понимал эту связь как один-к-одному.
> Т.е. "на пальцах" под каждую запись "наследника" существует
> запись в родительской таблице

Это при условии Mutually exclusive children. Так, например, с автомобилями.

А вот пример с Mutually inclusive children:
"Приказ по кадрам" может содержать либо только "приказ о назначении на должность", либо и "приказ о назначении на должность" и "приказ о назначении оклада".

← →
StriderMan © (2006-11-10 10:39) [12]

> Курдль © (10.11.06 10:27) [11]
> А вот пример с Mutually inclusive children

Понял идею. Пока с такой задачей не сталкивался, но спасибо.

← →
k2 © (2006-11-10 10:41) [13]

с ООП поосторожнее в базах, вот Джо Селко в книжке ругается:
"Некорректные имена элементов данных имеют своим источником невежество и объектно-ориентированное программирование (ООП)"
:))

← →
StriderMan © (2006-11-10 10:44) [14]

> k2 © (10.11.06 10:41) [13]
> с ООП поосторожнее в базах, вот Джо Селко в книжке ругается:
> объектно-ориентированное программирование (ООП)"

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

← →
k2 © (2006-11-10 10:48) [15]

ты блин даешь на Селко так говорить, ничего святого у молодежи :о)

← →
StriderMan © (2006-11-10 10:50) [16]

> k2 © (10.11.06 10:48) [15]

ляпнул не подумав видать :) все, ща камнями закидают

← →
pasha_golub © (2006-11-10 10:56) [17]

PostgreSQL изначально поддерживает такую модель. Есть правда некоторые ограничения в использованиях, вернее были. Они активно устраняются на данный момент. Конкретней почитать можно, например, здесь: http://www.postgresql.org/docs/current/static/ddl-inherit.html

Это документация по стабильной версии 8.1

http://developer.postgresql.org/pgdocs/postgres/ddl-inherit.html
Это документация по версии 8.2 Beta3

Есть ли различия не знаю.

← →
Курдль © (2006-11-10 11:00) [18]

> pasha_golub © (10.11.06 10:56) [17]
> PostgreSQL изначально поддерживает такую модель.

Да все РСУБД ее "поддерживают"!
Ведь наследование - это метод построения концептуальной модели, а не физической!

← →
Jeer © (2006-11-10 11:16) [19]

Курдль © (10.11.06 11:00) [18]

Тем не менее существуют РСУБД и ООСУБД - последние, могут то же, что и первые, но не наоборот.

← →
Курдль © (2006-11-10 11:26) [20]

> Jeer © (10.11.06 11:16) [19]
> Курдль © (10.11.06 11:00) [18]
>
> Тем не менее существуют РСУБД и ООСУБД - последние, могут
> то же, что и первые, но не наоборот.

Я бы так категорично не заявлял!
ООСУБД не могут очень многое из того, что могут РСУБД.
Но разве "наследование" отличает одни от других?

← →
Jeer © (2006-11-10 11:28) [21]

Разумеется.
Концептуально, РСУБД оперируют записями, ООСУБД - объектами.
Заметь, мы не о "клиентских" возможностях.

← →
StriderMan © (2006-11-10 11:30) [22]

> РСУБД и ООСУБД

а можно с примерами?

к ООСУБД можно отнести PostgreSQL?

← →
pasha_golub © (2006-11-10 11:32) [23]

> StriderMan © (10.11.06 11:30) [22]
>
>

> к ООСУБД можно отнести PostgreSQL?

Отчасти. Смесь РУСУБД и ООПСУБД, и именуется, по-моему, реляционно-объектной.

← →
Курдль © (2006-11-10 11:33) [24]

> Jeer © (10.11.06 11:28) [21]
> Разумеется.
> Концептуально, РСУБД оперируют записями, ООСУБД - объектами.
> Заметь, мы не о "клиентских" возможностях.

РСУБД "оперируют" сущностями, имеющими атрибуты, если уж на то пошло.
Сущности в РСУБД могут быть связаны различными типами связей, в том числе - наследственными.

← →
pasha_golub © (2006-11-10 11:36) [25]

> Курдль © (10.11.06 11:33) [24]

В реляционной алгебре разве существует тип связи "наследственный"?

Это вообще, своего рода, эксперимент на СУБД.
Объектными задумывались и создавались:
Itaska, Matisse, Jasmine, Object Store, Poet, Versant и тп.

В свое время мне пришлось делать выбор (обосновывать применение) между Jasmine и Cashe. Остановились на втором.
Так же, в свое время. пришлось поработать с иерархическими СУБД.

Так, что разницу между реляционными, иерархическими, сетевыми и объектными СУБД вполне понимаю.

> StriderMan © (10.11.06 11:30) [22]
> > РСУБД и ООСУБД
> а можно с примерами?
> к ООСУБД можно отнести PostgreSQL?

Примеры РСУБД - 99.9% всех, которые здесь обсуждаются.
ООСУБД известные мне - cache, versant.
Производители Последней распространяют бесплатные триальные версии СУБД и среды разработки, интегрированной в MS Visual Studio.

> StriderMan (10.11.2006 10:44:14) [14]

За маргинала ответишь :-)

> pasha_golub © (10.11.06 11:36) [25]
> В реляционной алгебре разве существует тип связи "наследственный"?

А кто сказал, что РСУБД построены на основе реляционной алгебры? 8-()
Реляционная алгебра - это основа выборок связанных наборов данных.

Курдль © (10.11.06 11:42) [29]

В основе тех или иных типов СУБД лежат некоторые математические и концептуальные основы.
В основе РСУБД лежит именно реляционная алгебра.

Более того, в Jasmine нет даже первичных ключей:)
А, например, ООСУБД ObjStore вообще работает с объектами, созданными в рамках обслуживающего языка (C++ или Java) и использует технологию виртуальной памяти, спроцеированной на БД.

> Jeer © (10.11.06 11:52) [30]
> В основе РСУБД лежит именно реляционная алгебра.

Не буду спорить, не имея под рукой соотв. документов и времени на их поиск.

> Более того, в Jasmine нет даже первичных ключей:)
> А, например, ООСУБД ObjStore вообще работает с объектами,
> созданными в рамках обслуживающего языка (C++ или Java)
> и использует технологию виртуальной памяти, спроцеированной
> на БД.

И что из того? Как это противоречит моим сентенциям?
Я тоже юзал ООСУБД от Versant и ее среду Fast Object.
Вся "работа" с этой базой ограничивается объявлением нужного класса
персистентным и дальше он начинает поддерживаться СУБД.
Т.е. при создании экземпляра этого класса он сразу же попадает в БД.
Так же происходит со всеми его членами.

В 1991 г. был создан консорциум ODMG (Object Data Management Group) - разработчики ООСУБД - вот он и отвечает за все последствия объектности.

В рамках этого стандарта были определены язык описания объектов (ODL) - аналог DDL, язык объектных запросов (OQL) - "select" из SQL92 является его подмножеством, что гарантирует обратную совместимость и стандарт связывания с внешними ООП языками (SmallTalk, C++, Java).

> Jeer © (10.11.06 12:09) [32]

Угу! Я почитываю "сопутствующую" литературу. :)
Но пока не могу похвастаться ни одним проектом, использующим ООСУБД.
Исследования, проведенные дружественными фирмами на этом рынке показали неприемлемое соотношение цена/качество.

> Jeer © (10.11.06 12:16) [34]
> У нас Cashe:)

И как она себя ведет на больших объемах? Сколько стоит?
Versant, например, заявил по-простецки $20 000 за лицензию.
Мы вспомнили, что первый оракл на 2 проца 10 лет назад мы покупали за $16 000 и прослезились (особенно как посчитали, что он в 10 раз подешевел).

Курдль © (10.11.06 12:20) [35]

Где-то в 2001-м эта акция состоялась.
Деньги - государевы, а патому..
Финансовую подоплеку не помню, но область на сухари не перешла.
На нем крутятся всякие мультимедийные проекты - полет нормальный.
Впрямую я с ним не связан.

Наследование в БД Найти похожие ветки