Модель данных
> Тогда чем определяется схема базы данных?
Связями и ограничениями.
Связями и ограничениями.
Связями
между чем?
Теоретически (иногда это удобно с практической точки зрения) любое отношение (реляционную таблицу) можно представить в виде отношения с тремя атрибутами
Ссылку в студию! Откуда следует, что любое отношение можно представить в таком виде?
Как в таком виде представить факт продажи некоего товара некоему клиенту в некоторый день? В данном случае факт продажи связывает три атрибута - день, продукт, клиент. Как эту связь представить в указанном виде, я не догоняю.
Ты не догоняешь - это ключ 
Я однозначно не догоняю - при чем тут ключ? Вполне может быть таблица без ключей. Да и вообще база данных может не содержать ни одного ключа.
Было высказано утверждение, что произвольное отношение можно представить в виде отношения из 3 полей. Я задал вопрос как отношение
(день, клиент, товар, объем продажи) представить в таком виде?
Было высказано утверждение, что произвольное отношение можно представить в виде отношения из 3 полей. Я задал вопрос как отношение
(день, клиент, товар, объем продажи) представить в таком виде?
Каждому кортежу присваиваем номер. Например, возьмем кортеж с номером 13
преобразуется в набор из четырех кортежей
<Клиент:Иванов, Товар:Сапоги, День:16.10.2004, объем_продажи:4>
преобразуется в набор из четырех кортежей
<id_строки:13, название_атрибута:Клиент, значение_атрибута:Иванов>
<id_строки:13, название_атрибута:Товар, значение_атрибута:Сапоги>
<id_строки:13, название_атрибута:День, значение_атрибута:16.10.2004>
<id_строки:13, название_атрибута:объем_продажи, значение_атрибута:4>
"искусственный" в данном рассуждении id_строки иногда имеет вполне разумное толкование, например, идентификатор (id) сделки
> между чем?
Между данными
или ты не это хотел услышать?
Между данными
или ты не это хотел услышать?
Получается ты берешь первоначальную модель данных, а затем ее уже приводишь к своему представлению, используя при этом дополнительный суррогатный ключ (в приведенном примере номер строки).
То есть для получения этой информации ты уже использовал знание о схему базы данных. Нужно ли продолжать отвечать на вопрос о том, зачем нужна схема базы даных?
То есть для получения этой информации ты уже использовал знание о схему базы данных. Нужно ли продолжать отвечать на вопрос о том, зачем нужна схема базы даных?
Тогда чем определяется схема базы данных? Удобством запросов? а что такое удобство? вы должны держать в голове все возможные виды запросов?
Попытаюсь понять, что ты хотел услышать от нас и отвечу на эту часть твоего запроса.
Можно выделить 2 класса баз данных: OLTP и OLAP.
OLTP предназначены для таких систем, как операционный день банка, система регистрации каких-то заказов и т.д.
OLAP - для аналитических целей.
Схема проектирования зависит в первую очередь от того, какая система строится OLTP или OLAP. Если это OLTP, то архитектор знает, что в его системе будет огромное количество очень простых запросов, и самое главное, чтобы все запросы были обработаны в приемлимое время, главное, чтобы ни одна транзакция не потерялась.
В OLAP будет совсем небольшое количество ОЧЕНЬ сложных запросов, и поэтому решаются совсем другие задачи оптимизации схемы базы данных.
Предложенный вариант хранения информации - ну очень неоптимален. Мне тяжело говорить про OLTP(я работаю с аналитическими системами) , но в OLAP такой подход кажется не то, что неправильным, а даже забавным %).
ты уже использовал знание о схему базы данных
это смотря как на это посмотреть
. Могу рассуждать так. В бизнесе, который я хочу автоматизировать, есть сущность Сделка. Присвоим каждой сделке уникальный идентификатор (обычная практика). У сделки есть набор атрибутов. Будем хранить данные о сделках в предложенной выше схеме. Твоя схема БД не упоминается P.S. кстати, в моей схеме набор атрибутов у разных сделок может быть разным, что часто бывает удобно
откуда поступают данные в OLAP системы?
Для того, чтобы твоя схема была идентична обычной тебе придется еще к каждой записи добавлять:
Иначе не получится выполнить запрос: дай мне все сделки.
ps
Часто те поля, которые не важны при построении запросов (которые не участвуют при построении фильтров) хранят в базе именно по твоей схеме,
это делается для того, чтобы не надо было менять базу под каждое изменение схемы данных
<id>, "что это такое", "сделка"
Иначе не получится выполнить запрос: дай мне все сделки.
ps
Часто те поля, которые не важны при построении запросов (которые не участвуют при построении фильтров) хранят в базе именно по твоей схеме,
это делается для того, чтобы не надо было менять базу под каждое изменение схемы данных
Вопрос номер раз - ты когда-нить базы проектировал? Встречался с проблемами?
Судя по всему нет.
Приведу примеры нескольких
1) Фактически у тебя получится одна единственная таблица - значит любой запрос по такой большой таблице будет выполняться дольше чем по маленьким.
2) Любой джойн у тебя будет выполняться не просто медленнее, а на порядки медленнее. При проектировании систем OLAP архитекторы часто идут на дублирование справочников, чтобы избежать соединения таблиц с самими собой, а тут у тебя фактически люой запрос будет вызывать такое соединение.
Судя по всему нет.
Приведу примеры нескольких
1) Фактически у тебя получится одна единственная таблица - значит любой запрос по такой большой таблице будет выполняться дольше чем по маленьким.
2) Любой джойн у тебя будет выполняться не просто медленнее, а на порядки медленнее. При проектировании систем OLAP архитекторы часто идут на дублирование справочников, чтобы избежать соединения таблиц с самими собой, а тут у тебя фактически люой запрос будет вызывать такое соединение.
откуда поступают данные в OLAP системы?
В классическом случае у предприятия множество OLTP систем, данные из которых объединяются в хранилище данных (OLAP).
> Тогда чем определяется схема базы данных?
Схема данных определяется прикладной областью (задачей, решаемой в конкретной прикладной области).
Соответственно схема БД определяется на основе схемы данных, и здесь уже можно говорить, какую часть схемы данных мы переносим в базу данных, а какую часть оставляем в уме.
При этом говорится, что чем схема БД будет ближе к схеме данных прикладной области, то тем проще и полнее можно будет описывать запросы, а также тем проще базе проверить правильность данных.
ps
Схема данных - это данные (элементы связи между данными (элементами) и ограничения на данные и связи
Схема данных определяется прикладной областью (задачей, решаемой в конкретной прикладной области).
Соответственно схема БД определяется на основе схемы данных, и здесь уже можно говорить, какую часть схемы данных мы переносим в базу данных, а какую часть оставляем в уме.
При этом говорится, что чем схема БД будет ближе к схеме данных прикладной области, то тем проще и полнее можно будет описывать запросы, а также тем проще базе проверить правильность данных.
ps
Схема данных - это данные (элементы связи между данными (элементами) и ограничения на данные и связи
Согласен,
могу только добавить, что в системах OLAP на первом месте оказывается решаемая задача,а на втором предметная область.
могу только добавить, что в системах OLAP на первом месте оказывается решаемая задача,а на втором предметная область.
Вопрос номер раз - ты когда-нить базы проектировал? Встречался с проблемами?
Судя по всему нет.
Читай внимательнее, первое слово в это треде "Теоретически". Вопрос производительности вообще не поднимался. Производительность сейчас меня не интересует.
Читай внимательнее, первое слово в это треде "Теоретически". Вопрос производительности вообще не поднимался. Производительность сейчас меня не интересует.
Раз уходим в терию, то вспоминаю любимую фразу моего научника:
"Главный вопрос информатики - А ЗАЧЕМ?"
Есть куча методологий проектироания баз данных, взамен предлагается проектировать "в лоб". Вопрос - в чем прикрол? %)
объединяются
в каком смысле? любую информацию, которая есть в OLTP системах, я могу получить из хранилища данных?
что такое данные (элементы)? и связи между данными (элементами)?
ps я не придираюсь, мне действительно интересно
ps я не придираюсь, мне действительно интересно
Ладно, прочитаю лекцию:
Представь себе банк - у него есть куча OLTP систем - например, Опер день банка, система обслуживающая банкоматы, система поддерживаяющая департамент кредитования ит.д. и т.п. У нормального банка число атких систем измеряется десятками и сотнями. При этом данные системы работают под управлением софта от разных производителей для кадлой из них есть отдельная база данных, при этом возможно под управлением разных СУБД. Теперь представь себе руководство этого банка, которому по большому счету неинтересно смотреть отдельные отчеты по банкоматам, по кредитному подразделению и т.д. Он хочет видеть цельную картину по всему банку. Для этого он нанимает отдельную команду, которая строить аналитическую базу данных, в которую собирается информация из всех OLTP систем. При этом схема этой базы имеет очень маол общего со схемой начальной базы данных.
Далее, в больших системах OLTP обычно хранится не очень исчторичная информация. Например, ыт можешь получить информацию о движении средств по твоему счету за последнйи месяц, но за 3 последних года такой информации тебе не дадут, потмоу что ее никто не хранит. Чтобы OLTP-система оставалась рабочей, надо чтобы она была разумного размера, поэтому соответсвующая инфомация из OLTP через некоторое время удаляется. Если же информация попала в аналитическую систему, то она не удаляется никогда, а хранится вечно, на случай если руководство захочет проанализировать информацию за последние 10 лет.
Соответсвенно есть примеры того, что информация есть в ОЛАП, но ее нет в ОЛТП.
И наоборот - банк может генерировать миллиарды транзакций в месяц, поэтому если мы будем хранить их все в хранилище, то это также может оказаться слишком расточительно. В зависимости от аздачи, возможно имеет смысл хранить некоторые итоговые данные, например, результат проводок за день и т.д.
Представь себе банк - у него есть куча OLTP систем - например, Опер день банка, система обслуживающая банкоматы, система поддерживаяющая департамент кредитования ит.д. и т.п. У нормального банка число атких систем измеряется десятками и сотнями. При этом данные системы работают под управлением софта от разных производителей для кадлой из них есть отдельная база данных, при этом возможно под управлением разных СУБД. Теперь представь себе руководство этого банка, которому по большому счету неинтересно смотреть отдельные отчеты по банкоматам, по кредитному подразделению и т.д. Он хочет видеть цельную картину по всему банку. Для этого он нанимает отдельную команду, которая строить аналитическую базу данных, в которую собирается информация из всех OLTP систем. При этом схема этой базы имеет очень маол общего со схемой начальной базы данных.
Далее, в больших системах OLTP обычно хранится не очень исчторичная информация. Например, ыт можешь получить информацию о движении средств по твоему счету за последнйи месяц, но за 3 последних года такой информации тебе не дадут, потмоу что ее никто не хранит. Чтобы OLTP-система оставалась рабочей, надо чтобы она была разумного размера, поэтому соответсвующая инфомация из OLTP через некоторое время удаляется. Если же информация попала в аналитическую систему, то она не удаляется никогда, а хранится вечно, на случай если руководство захочет проанализировать информацию за последние 10 лет.
Соответсвенно есть примеры того, что информация есть в ОЛАП, но ее нет в ОЛТП.
И наоборот - банк может генерировать миллиарды транзакций в месяц, поэтому если мы будем хранить их все в хранилище, то это также может оказаться слишком расточительно. В зависимости от аздачи, возможно имеет смысл хранить некоторые итоговые данные, например, результат проводок за день и т.д.
что такое данные (элементы)? и связи между данными (элементами)?
Обычно в начале проекта после общения с представителями заказчика выявляются различные виды объектов, например, заказ, накладная, клиент, группа клиентов, продукция и т.д.
Если мы выявили такие бизнес-объекты, то значит заказчику интересны данные, связанные с этими бизнес-объектами. Вот здесь и появляются ДАННЫЕ.
Далее мы анализируем как бизнес-объекты связаны друг с другом, например у одного клиентов может быть несколько заказов, у одного клиента ровно один адрес доставки. В группу клиентов входят несколько клиентов - так выявляются связи между объектами, а как следствие и связи между данными.
Данные - это данные или другими словами - это элементы, сущности, объекты.
Если в примерах, то это число, строка, машина, кошка, человек, должность и т.д.
Связи - это отношения между этими данными, зависимости.
Виды связей: родитель<->ребенок, общее<->частное и т.д.
пример, Родитель<->ребенок
есть элемент книга
есть элемент имя
между этими элементами есть связь родитель<->ребенок, т.к. имя не может существовать без машины
Общее<->частное - для этой связи можно смотреть стандартные примеры из ООП.
ps
Зависимости - это может уже ближе к ограничениям.
или другими словами - это элементы, сущности, объекты.Если в примерах, то это число, строка, машина, кошка, человек, должность и т.д.
Связи - это отношения между этими данными, зависимости.
Виды связей: родитель<->ребенок, общее<->частное и т.д.
пример, Родитель<->ребенок
есть элемент книга
есть элемент имя
между этими элементами есть связь родитель<->ребенок, т.к. имя не может существовать без машины
Общее<->частное - для этой связи можно смотреть стандартные примеры из ООП.
ps
Зависимости - это может уже ближе к ограничениям.
кстати, вы с по-разному понимаете данные, у тебя кошка это данное, а у него данные связаны с кошкой. Я так понимаю, у данные это что то типа строк, чисел, картинок и т.д.
Видимо, неудачно выразился. Попытаюсь объяснить.
Вначале происходит моделирование логической модели данных. Тут появляется Кошка, как ее понимает бизнес-пользователь
Далее происходит физическое моделирование данных, то есть в каких табличках эта кошка будет храниться %).
И там и там есть кошка - просто эти кошки находятся на разных уровнях абстракции%).
Вначале происходит моделирование логической модели данных. Тут появляется Кошка, как ее понимает бизнес-пользователь
Далее происходит физическое моделирование данных, то есть в каких табличках эта кошка будет храниться %).
И там и там есть кошка - просто эти кошки находятся на разных уровнях абстракции%).
но кошку-то он тоже хранит, хотя бы в виде int-ового идентификатора.
ps
Если у нас есть таблица кошки, то добавление записи в эту таблицу приводит к хранению именно кошки, т.е. в рамках БД: сами кортежи и аттрибуты кортежа соответствует данным из прикладной области
ps
Если у нас есть таблица кошки, то добавление записи в эту таблицу приводит к хранению именно кошки, т.е. в рамках БД: сами кортежи и аттрибуты кортежа соответствует данным из прикладной области
тк у меня тоже есть кошка 
(в первом посте)
(в первом посте)Часто те поля, которые не важны при построении запросов (которые не участвуют при построении фильтров) хранят в базе именно по твоей схеме, это делается для того, чтобы не надо было менять базу под каждое изменение схемы данных
>которые не участвуют при построении фильтров
по соображениям производительности?
меня сейчас больше интересует затраты связанные с реализыцией и сопровождением.
Для того, чтобы твоя схема была идентична обычной тебе придется еще к каждой записи добавлять:
code:--------------------------------------------------------------------------------<id>, "что это такое", "сделка"
это тоже можно засунуть в ту единственную табличку
И наоборот - банк может генерировать миллиарды транзакций в месяц, поэтому если мы будем хранить их все в хранилище, то это также может оказаться слишком расточительно. В зависимости от аздачи, возможно имеет смысл хранить некоторые итоговые данные, например, результат проводок за день и т.д.
таким образом, слово "объединяет" тут имеет не обычный смысл. Тогда чем определяется какая информация храниться в хранилище данных? запросами топ-менеджеров? а они могут точно сказать какая информация им будет нужна? В идеале руководитель должен иметь быстрый доступ к любой информации о своем предприятии.
дык, в общем случае, и твое описание, и стандартное описание имеет право на жизнь.
твое описание универсальнее, стандартное описание специализированнее.
Соответственно, твое, за счет универсальности, подходит для описания большего числа задач, но стандартное описание, за счет специализированности, позволяет удобнее решать задачи.
Допустим нам надо задать, что у каждой кошки должно быть имя (одно и только одно).
В твоем случае, это будет что-то такое:
для каждого id, где имя-аттрибута='тип' && значение-аттрибута='кошка' должно выполняться условия:
count(select * where id=source_id && имя-аттрибута="name") = 1 и
not null (select значение-аттрибута where id=source_id && имя-аттрибута="name")
для стандартного определения будет:
table кошка
not null name
твое описание универсальнее, стандартное описание специализированнее.
Соответственно, твое, за счет универсальности, подходит для описания большего числа задач, но стандартное описание, за счет специализированности, позволяет удобнее решать задачи.
Допустим нам надо задать, что у каждой кошки должно быть имя (одно и только одно).
В твоем случае, это будет что-то такое:
для каждого id, где имя-аттрибута='тип' && значение-аттрибута='кошка' должно выполняться условия:
count(select * where id=source_id && имя-аттрибута="name") = 1 и
not null (select значение-аттрибута where id=source_id && имя-аттрибута="name")
для стандартного определения будет:
table кошка
not null name
> по соображениям производительности?
в том числе,
а также из-за того, что сами условия фильтров в твоем случае будут записываться в виде трехэтажных выражений.
в том числе,
а также из-за того, что сами условия фильтров в твоем случае будут записываться в виде трехэтажных выражений.
таким образом, слово "объединяет" тут имеет не обычный смысл. Тогда чем определяется какая информация храниться в хранилище данных? запросами топ-менеджеров? а они могут точно сказать какая информация им будет нужна? В идеале руководитель должен иметь быстрый доступ к любой информации о своем предприятии.
Конечно же необычный. Я назвал это дело объединение - для очень сильного упрощения. Я же небуду сейчас пересказывать огромные книги по данной тематике. Это действительно очень сложная и не так просто формализуемая задача. Боюсь, твой подход не приведет к какому либо упрощению ее решения.
Боюсь, твой подход не приведет к какому либо упрощению ее решения.
я даже и не думал об этом, просто тема OLAP затронулась в этом треде, поэтому я и задал вопросы об OLAP
меня сейчас больше интересует затраты связанные с реализыцией и сопровождением.
Возможно реализовать такую систему будет и проще. Может быть можно написать универсальный скрипт который будет генерить такую базу. Но поддерживать и расширять такую систему, когда она будет действительно большой... сомневаюсь.
я даже и не думал об этом, просто тема OLAP затронулась в этом треде, поэтому я и задал вопросы об OLAP
Да в общем-то пожалуйста, я на эту тему люблю потрепаться %)
Это действительно очень сложная и не так просто формализуемая задача.
вот вот, а иначе обучили бы компьютеры это делать, поскольку информация уже находится (или проходит через) в компьтерах (в OLTP)
вот вот, а иначе научили бы это делать компьютеры, поскольку информация уже находится (или проходит через) в компьтерах (в OLTP)
Не стоит пытаться упростить ВСЕ на свете. Если бы все было просто, то мы остались бы без работы %).
у Microsoft лозунг "Сделаем мир проще", и деньги они неплохие зарабатывают.
Фишка в том, что если это можно упростить, то скорее всего найдется умник, который это сделает, вот тогда мы действительно останимся без работы.
Фишка в том, что если это можно упростить, то скорее всего найдется умник, который это сделает, вот тогда мы действительно останимся без работы.
Да любой мало-мальски нетривиальный запрос убъет эту базу нафиг это будет full table scan и все сдохнет.
В теории-то все красиво, но именно из-за таких вот проблем стухли все объектные СУБД.
это будет full table scan и все сдохнет.В теории-то все красиво, но именно из-за таких вот проблем стухли все объектные СУБД.
у Microsoft лозунг "Сделаем мир проще", и деньги они неплохие зарабатывают.
Мне нравится другой лозунг, к сожалению, не вспомню чей копирайт, и прошу прощения за неточную цитату:
"Простые вещи должны делаться просто, сложные должны быть реализуемы"
Да любой мало-мальски нетривиальный запрос убъет эту базу нафиг это будет full table scan и все сдохнет.
full scan не самое плохое, что там может случиться. Самое плохое это джойны.
В теории-то все красиво, но именно из-за таких вот проблем стухли все объектные СУБД.
Да вроде Cache где-то применяется, так что не стухли окончательно...
Cache - не объектная база. И не реляционная. Зато им удалось истребить джойны, а это уже неплохо.
... но стандартное описание, за счет специализированности, позволяет удобнее решать задачи.
Допустим нам надо задать, что у каждой кошки должно быть имя (одно и только одно).
В твоем случае, это будет что-то такое:
для каждого id, где имя-аттрибута='тип' && значение-аттрибута='кошка' должно выполняться условия:
count(select * where id=source_id && имя-аттрибута="name") = 1 и
not null (select значение-аттрибута where id=source_id && имя-аттрибута="name")
для стандартного определения будет:
table кошка
not null name
На SQL- е это выглядит сложно, поскольку SQL разрабатывался как раз для обычной реляционной модели. Просто SQL здесь не удобно использовать, а какой-то принципиальной трудности (которая, в частности, мешала бы создать удобный язык) я пока не вижу.
На самом деле, когда указываешь
table кошка
not null name
появляется соответсвующая запись в системной таблице СУБД.
Теоретически можно разрешить писать в системные таблицы напрямую, и, пожалуйста, придумывай удобный для себя способ ввода.
> На SQL- е это выглядит сложно, поскольку SQL разрабатывался как раз для обычной реляционной модели.
В первом твоем посте явно упоминалась реляционная модель.
Поэтому ответ такой: в реляционной модели предложенный тобой способ не удобен.
Если хочешь обсудить свой способ задания данных для других моделей, то задай оригинальный вопрос по другому
В первом твоем посте явно упоминалась реляционная модель.
Поэтому ответ такой: в реляционной модели предложенный тобой способ не удобен.
Если хочешь обсудить свой способ задания данных для других моделей, то задай оригинальный вопрос по другому
Оставить комментарий
6yrop
Теоретически (иногда это удобно с практической точки зрения) любое отношение (реляционную таблицу) можно представить в виде отношения с тремя атрибутамиЕсли это проделать с каждым отношением базы данных и ввести уникальные id_строки (например, GUID то все данные можно хранить в одном отношении (таблице).
Тогда чем определяется схема базы данных? Удобством запросов? а что такое удобство? вы должны держать в голове все возможные виды запросов?