NewbieArchitectПроектировщики, скажите как это делается по уму. Есть спроектированная БД. Далее необходимо создать модель классов для клиента. Как это делается, есть ли какие-то принципы и правила?
Или просто таблица = класс ? Или объектно-ориентированная модель создается руками и не имеет отношения к БД?
Спасибо.

Класс моделирует структуру таблицы. Соответственно объект моделирует запись в таблице. Большинство GUI приложений имеют структуру классов однозначно соответствующую структуре реляционной БД. Для этих целей даже давно разработаны библиотеки компонентов доступа к данным. Приложения, которые самостоятельно изменяют данные должны ещё иметь набор классов, которые реализуют прикладные функции, но могут не иметь отражения в БД.

мод NewbieArchitectЕсть, допустим, таблица КЛИЕНТ в БД. Соответсвенно, придется создавать класс КЛИЕНТ в приложении.
Не придется - продолжайте работать с таблицами.

? Это как? Таблица это объект базы данных. За пределами базы данных в прикладных процессах нужно создавать временные копии записей базы данных, а для этого нужны соответствующие структуры данных ориентированные на решение конкретной задачи.
Пока модель данных не касается вопросов размещения объектов времени выполнения мы обычно можем не различать классы объектов БД и приложения. В процессе моделирования модуля приложения и модуля БД различия в поведении объектов БД и приложения начнут проявляться. Например, объект приложения живёт только в пределах его процесса, соответственно этот объект должен поддерживать функции сохранения в БД и восстановления из неё. Объекту БД эти функции не требуются. Довольно часто такое базовое поведение уже реализовано в библиотеке доступа к данным, так что генерация классов приложения из сущностей БД является формальной процедурой.

Сергей Васкецов mcureenab? Это как?
Я так понимаю, что человеку намекнули, что не всегда необходимо создавать в клиенте на каждый справочник по классу.

Так речь то вроде не про справочники... Если все справочники структурно и функционально одинаковые, то создавать под каждый справочник отдельный класс есть смыс когда это происходит автоматически. Возможно, что в перспективе пути справочников могут разойтись, и тогда будет не так просто выяснять в коде для каких объектов нужно менять тип.

Сергей ВаскецовСобственно, еще большой вопрос, когда необходимо создавать классы один в один в соответствии со структурой БД. На ум приходит только академический интерес.

Почему?.. Oracle Type Translator (OTT) так и поступает. Для каждого типа БД он генерит эквивалентную конструкцию на языке C. Тут ситуация классическая, самые простые варианты - не генерить классы вообще или генерить 1:1. Все прочие ситуации выглядят определённо сложенее при том что покрывают только весьма частные решения.

мод mcureenab? Это как?
Истина всегда конкретна :)
1. На экране грид = recordset (курсор и т.д.)
2. На экране форма = join одной записи одной таблицы с несколькими записями нескольких других таблиц
3. Расчеты по БД - прямая работа с recordset -ами (курсорами)
Какие еще объекты нужны ?

Что то мне подсказывает, что во всех перечисленных случаях мы создаём класс приложения соответствующий сущности ER-модели. Этот класс наследует структуру сущности и определяет методы взаимодействия с СУБД и с графическеой подсистемой ОС. Даже если мы имеем дело с динамическим построением нового класса в Runtime, всё равно такой класс будет создан. Остаётся только решить, нужно ли его моделировать или можно сразу приступить к реализации.

softwarer mcureenabOracle Type Translator (OTT) так и поступает.
Cуществует уйма тупых инструментов, которыми никто не пользуется.

mcureenabТут ситуация классическая, самые простые варианты - не генерить классы вообще или генерить 1:1.
Из них второй не имеет практического смысла, если говорить о приложениях сложнее записной книжки. Да и для записной книжки выгод нет, просто нет и явных проблем.

Два ничем не обоснованных утверждения. По крайней мере по п.2 для генерации кода я сам выбрал стратегию 1:1 и успешно её применил для решения практических задач.

softwarer mcureenabДва ничем не обоснованных утверждения.
Ошибаетесь. Первое из них обосновано простейшей статистикой - зайдите в гугль и посмотрите, сколько раз вообще упоминается в мире эта замечательная технология.

Для сравнения: даже о другой мертвой технологии, родившейся примерно в то же время, "Oracle Objects For OLE" упоминаний на два порядка (!) больше.

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

mcureenabПо крайней мере по п.2 для генерации кода я сам выбрал стратегию 1:1 и успешно её применил для решения практических задач.
Из того, что Вы способны успешно дойти пешком из Москвы до Питера не следует, что этот вариант имеет практический смысл. Для наличия смысла нужно хоть какое-то преимущество над альтернативами.[/quot]

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

softwarer mcureenabПреимущество как минимум в том, что оно сделано и работает
Замечательное обоснование. Итого, любая работающая программа имеет преимущество уже в силу своего существования. Интересно только, над кем. Судя по контексту - над несуществующими; других альтернатив Вы не рассматриваете.

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

мод mcureenabЧто то мне подсказывает, что во всех перечисленных случаях мы создаём класс приложения соответствующий сущности ER-модели.
Нет. Мы уже перешли от сущностей к рел. таблицам специально для того, что бы применять рел. операции. Вся обработка, в.т.ч. и отображение в UI, выполняется в терминах таблиц (м.б. и виртуальных).

Понятно. Только чел сейчас хочет построить модель, а не приложение. Т.е. он хочет поработать на уровне ER модели и модели классов. Не знаю зачем ему это надо. Возможно требуется сохранить семантику модели, которая неизбежно будет потеряна при переходе на уровень таблиц и компонентов доступа к данным.

Тем не менее я не склонен отождествлять компоненты доступа к данным и таблицы даже при наличии взаимно однозначной трассировки. Компоненты доступа к данным работают с выборками, а не с таблицами, а выборка имеет гораздо больше полезных для приложения свойств, чем БД, например выборка может быть отфильтрована и упорядочена.

Сергей Васкецов mcureenab мод mcureenab? Это как?
Истина всегда конкретна :)
1. На экране грид = recordset (курсор и т.д.)
2. На экране форма = join одной записи одной таблицы с несколькими записями нескольких других таблиц
3. Расчеты по БД - прямая работа с recordset -ами (курсорами)
Какие еще объекты нужны ?

Что то мне подсказывает, что во всех перечисленных случаях мы создаём класс приложения соответствующий сущности ER-модели
Ну, даже если классом считать саму форму, на которой это все валяется, все равно это бред. У меня по порядку величины тысяча таблиц в модели, но ни одного объекта в терминах ООП на клиенте, который бы характеризовал сущности модели, нет. Просто потому, что их не надо для работы.

И что? Если Вы для разработки приложений используете процедурный подход, то классы и объекты не выделяются. Короче, пишите конкретно, о каких приложениях и средствах разработки идёт речь и как они соотносятся с объектным моделированием. И не забываем про то, что на уровне оборудования все данные и код есть просто массивы битов.

softwarer mcureenabДа. В силу существования любая существующая программа лучше несуществующей
Короче говоря, Вы закольцевали логику: взяли первую попавшуюся хрень, использовали ее, и поэтому она хороша, ее нужно использовать.

Прошу не передёргивать. Хрень, была выбрана из многих других хрененей, найденая хрень меня вполне устраивает, из чего я делаю вывод что её можно использовать и её использование имеет смысл.

мод mcureenab
Компоненты доступа к данным работают с выборками, а не с таблицами, а выборка имеет гораздо больше полезных для приложения свойств, чем БД, например выборка может быть отфильтрована и упорядочена.
Выборка как результат рел. операции это тоже таблица. Сортировка ничего принципиально не меняет.


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

мод mcureenab
Только чел сейчас хочет построить модель, а не приложение. Т.е. он хочет поработать на уровне ER модели и модели классов.
Т.е. работать не с таблицами, а с объектами ? Так тоже можно, но тогда надо забыть о таблицах, рел. модели и пр. Можно использовать какую-нибудь ОСУБД или сделать собственную.

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

Объекты приложения отличаются от объектов БД. В процессе копирования записи из БД в процесс приложения (через интерфейс курсора БД, который возвращает выборку) происходит преобразование типов данных, структуры и т.п. Даже если мы на высоком уровне абстракции говорим о том, что запись в базе данных и объект в приложении имеют один и тот же класс, то на уровне реализации мы создаём разные типы - например тип struct в C++, и DDL оператор create table в SQL. Наконец в результате сборки, мы получаем исполняемый код для работы со структурой данных на ПК и таблицу как объект схемы БД.

Чтобы привнести конкретики, рассмотрим Oracle Forms.
Во время разработки мы создаём блок формы (block) и добавляем в него элементы (item). По сути мы конструируем новый класс. Определённо блок формы, это совсем не таблица БД. Он может даже содержать записи, которых и нет вовсе в БД, да и SQL запросы к нему не применимы. Но на более высоком уровне абстракции мы видим, что блок формы реализует некоторую часть поведения хранимого объекта, обычно связанную с его редактированием в GUI.

В отличии от классов C++ блоки и элементы формы имеют предопределённые виртуальные методы - триггеры, которые разработчик может перегрузить своим кодом. Объекты C++ живут в стеке, глобальной памяти или в куче, объекты Forms, живут только в блоке формы. Есть и другие отличия. Кто то может сказать, что аналогия вообще притянута за уши, однако подход вполне продуктивный и пока он позволяет решать задачи моделирования и генерации кода, я его буду использовать.

мод mcureenabОпределённо блок формы, это совсем не таблица БД.
Это просто таблица - результат select-a - но всяко не класс.

Короче, Вы всё сущее называете таблицами, а раз так, обсуждать различия разных видов "таблиц" непредставляется возможным.

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

мод mcureenabКороче, Вы всё сущее называете таблицами
Совсем нет. Возьмем пример: сущность: счет-фактура, в РБД представлена 2-мя таблицами: заголовки и строки. Приложение работает с этими таблицами вместе или по отдельности.
"Объектный вариант: в ОБД СФ хранится как объект класса СФ, никаких таблиц нет, приложение работает с каждым СФ как с единым объектом.
Можно сравнить эти два варианта.

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