Никто и не обижается. :)

Вообще-то, в основе реляционных СУБД лежит реляционная модель, а условие целостности данных является одной из составляющих этой модели.

Эээ, сам факинг еррорс:
было
CONSTRAINT SomeParentTable_FK1 FOREIGN KEY (ParentID) REFERENCES SomeChildTable(ParentID) ON DELETE CASCADE
нужно:
CONSTRAINT SomeChildTable_FK1 FOREIGN KEY (ParentID) REFERENCES SomeParentTable(ParentID) ON DELETE CASCADE

Пятница, вечер блин. Сами знаете с бутылочкой чего в руке.

Лениво читать весь тред.

Самое забавное - в начале неделе было сообщение о том, что Оракл стал партнером микрософт...

С MS дружи, да сам не плошай.

А они и не плошают, по сему переходят с САНок, на что-то другое.

>Самое забавное - в начале неделе было сообщение о том, что Оракл стал партнером микрософт...

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

эх... опять же небось у ирси не спросили - стоит переходить или нет :)) как же так

> И еще, вопрос к МоимЭскуэлистам: OARCLE 8.1.7.4. 1e6 записей логов в день. Размах строки <= 2К. Логи нужно хранить в течении года. Это решается както на МоемЭскуэле?????

Не скажу за MySQL, но PostgreSQL от него ушел не очень далеко. Тоже не претендует на кластерные решения и супер-дупер интеграцию со всем и вся. Обычная база данных с открытым кодом, все остальное - своими руками. Может и мощнее мускула, но класс тот-же...

Так вот, на постгресе реализуется следующее:

Требования: 2e7 записей в сутки, пиковая нагрузка 1.5e6 записей в час. Каждая запись сначала появляется в базе данных, потом требует изменений. Средний интервал между вставкой и обновлением - 40 секунд, максимальное время более суток. Максимальный интервал между регистрацией события в системе и появлением записи в базе данных не более 30 секунд. Данные нужно хранить за месяц, плюс почасовая статистика за весь год. За текущий месяц система долна выдавать статистику за произвольный период времени, по большому числу критериев. Размер одной записи более 20 полей, часть из них текстовая длиной не более 18 символов.

Реализовано на интеловской платформе, двухпроцессорный сервер и raid5+1. Работает более двух лет.

Ораклу было отказано из-за высокой стоимости, которая существенно влияла на общую цену решения.

>И еще, вопрос к МоимЭскуэлистам:OARCLE 8.1.7.4. 1e6 записей логов в день. Размах строки <= 2К. Логи нужно хранить в течении года. Это решается както на МоемЭскуэле?????

Ну а почему же не решается? Требует конечно настройки, но вполне решаемо. Например с помощью merge таблиц.

Да и без merge таблиц решаемо. Конечно на нормальном железе, не на десктопном писюке.

> Вообще-то, в основе реляционных СУБД лежит реляционная модель,
> а условие целостности данных является одной из составляющих этой
> модели.

В основе реляционной модели лежит реляционная алгебра (раздел маетматики такой). А "условие целостности" имеет отношение только к прикладным аспектам реализации, и не имеет никакого касательства к реляционности, а только к программированию и проектированию.

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

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

> В основе реляционной модели лежит реляционная алгебра (раздел маетматики такой).

Никто и не спорит.

> А "условие целостности" имеет отношение только к прикладным аспектам реализации, и не имеет никакого касательства к реляционности, а только к программированию и проектированию.

Да? Так когда вводится понятие целостности данных? Разве не тогда, когда говорим о реляционной модели данных?

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

Ограничение или задание множества значений типа является одним из методов поддержания целостности реляционной модели данных. :)

> Да? Так когда вводится понятие целостности данных?

На уровне реализации.

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

Для того, чтобы структура данных была реляционной, необходимо и достаточно, чтобы данные были организованы в отношения (таблицы), которые являются множествами кортежей (записей), в которых значение каждого атрибута (поля записи) принадлежит к соответствующему домену, а также реализованы операции произведения, сложения, вычитания и проекции отношений (в переложении для анонимусов - построение результирующей таблицы по двум другим по принципу "каждый с каждым" [произведение], объединение двух таблиц посредством union [сложения], выборка из таблицы записей не встречающихся во второй таблице [вычитание], и построение таблицы включающей только некоторые поля из таблицы [проекция]. Любая СУБД, позволяющая реализовать указанные требования и операции, является реляционной.

> Ограничение или задание множества значений типа является одним
> из методов поддержания целостности реляционной модели данных

Поддержание целостности - это функция СУБД, но не свойство модели данных. Вы еще скажите, что Oracle не является SQL-сервером, поскольку в его названии не содержится словосочетания "SQL-сервер"...

Так что, идите-ка вы в... Ну, например, в сборщики персоналок - ибо даже до "поддержки пользователей", работающих с базами данных, вас с такими знаниями допускать нельзя (не говоря уже о разработке).

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

> Даже если не устанавливать никаких триггеров, ключей и т.п., а просто задать типизацию для полей указанных таблиц, приведенная структура уже ЯВЛЯЕТСЯ реляционной базой данных

Как ты обеспечишь уникальность кортежей в отношении без задания первичного ключа?

> Для того, чтобы структура данных была реляционной, необходимо и достаточно, чтобы данные были организованы в отношения (таблицы), которые являются множествами кортежей (записей), в которых значение каждого атрибута (поля записи) принадлежит к соответствующему домену, а также реализованы операции произведения, сложения, вычитания и проекции отношений

Ну вот, про структуру и набор операций ты прочитал, а про целостность забыл.

> Поддержание целостности - это функция СУБД, но не свойство модели данных.

Пойми, целостность --- это фунция реляционной СУБД, так как является свойством реляционной модели данных. Читай книги внимательней --- мой тебе совет.

Реляционная модель

Анонимус, вы... В общем, вы непонятливы.

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

Связи и целостность проявляются только на уровне реализации и проектирования схемы таблиц.

> Как ты обеспечишь уникальность кортежей в отношении без задания первичного ключа?

А какое отношение первичный ключ имеет к поддержанию целостности??

http://en.wikipedia.org/wiki/Relational_model

>>А какое отношение первичный ключ имеет к поддержанию целостности??

Его уникальность это целостность?

> А какое отношение первичный ключ имеет к поддержанию целостности??

Самое прямое. Когда говорим о целостности структуры данных, говорим в том числе и о первичных ключах.

За ссылку спасибо.

Если у тебя под рукой нет книги по ТРБД, то нужная тебе информация находится здесь: http://en.wikipedia.org/wiki/Data_model.

> Когда говорим о целостности структуры данных, говорим в том числе и о первичных ключах.

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

Кстати, действительно интересно. Вот что по этому поводу написано в википедии:

"It [relational model] furthermore defines a set of specific constraints (primary keys, candidate keys, foreign keys) and a general language for specifying constraints"

Вот так вот. А я уже не помню, что по этому поводу было у Дейта, и под рукой нет...

Буржуи часто смешивают науку с практикой, а у no-dashi подход более академический. Наверное, вы - оба правы, но каждый - по-своему :)

Просто первичные ключи (наряду с ограничениями типов и атрибутов) определяются при описании структуры данных реляционной модели, а когда заходит разговор о целостности, они упоминаются как один из механизмов ее поддержания.

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

> Связи и целостность проявляются только на уровне реализации и проектирования схемы таблиц.

К. Дж. Дейт "Введение в системы баз данных" (7е издание) - достаточно авторитетный источник?

Часть 1. Основные понятия. Глава 3. Ведение в реляционные базы данных

3.2 Реляционная модель

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

> Структурный аспект. Данные в базе воспринимаются пользователем, как таблицы.

> Аспект целостности. Эти таблицы удовлетворяют определённым условиям целостности.

> Аспект обработки. В распоряжении пользователя имеются операторы манипулирования данными..."

Далее, часть 2, "Реляционная модель", состоит из 5 глав: "Домены, отношения и базовые переменные-отношения", "Реляционная алгебра", "Реляционное исчисление", "Целостность данных", "Представления".

Так что, насколько я понимаю, по Дейту реляционная алгебра != реляционная модель, но входит в неё.

Реляционная модель

2 НетДаши

У мускуля до 4-й версии небыло UNION, так это значит, что она - не реляционная БД. :) Ну, это шутка.


2 Прерывание
> Целостность обеспечивается (помимо прочего) внешними ключами.
А что такое внешний ключ?

> А существование первичного ключа в любом отношении - это
> просто неотъемлимое свойство реляционной модели.

А существование потенциального клуча в любом отношении - это тоже "просто неотъемлимое свойство реляционной модели"?

> А что такое внешний ключ?

Как утверждает мой лингво, "внешний ключ" переводится как "foreign key". И здесь я склонен с ним согласиться.

> А существование потенциального клуча в любом отношении - это тоже "просто неотъемлимое свойство реляционной модели"?

А что, нет? И вообще, обеспечивать уникальность кортежей в отношении - это даже мускуль умеет ;)

Или ты с меня потребуешь определение "по книжке"?

>Он превращается в какое-то майкрософто-подобное говно.

Oracle как был хорошей БД так в ближайшее время ей и останется и ни MySQl ни Postgre его не догонят никогда. Так что ещё очень и очень долго заменить его будет не чем. Я имею в виду канешна большие серьёзные базы для web ради бога берите MySQL там Oracle ему не конкурент ему это вообщем то и не надо. Ну не будете же вы катерпиллер 180 тонный в детскую песочницу загонять.

Насколько я понимаю речь идет о правилах 10, 12??? Видимо подразумевается DDL?

12 правил Кодда ( знаете такого перца? )

0. Реляционная СУБД должна быть способна полностью управлять базой данных, используя связи между данными.

1. Информационное правило - Вся информация в реляционной БД (включая имена таблиц и столбцов) должна определяться строго как значения таблиц.

2. Гарантированный доступ - Любое значение БД должно быть гарантированно доступным через комбинацию имени таблицы, первичный ключ и имя столбца.

3. Поддержка нулевого значения - СУБД должна уметь работать с нулевыми (пустыми) значениями. Нулевое значение - это неизвестное, независимое, неприменимое значение, в отличие от значений по умолчанию и обычных значений.

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

5. Исчерпывающее подмножество языка данных - По крайней мере, один из поддерживаемых языков должен иметь четко определенный синтаксис и быть самодостаточным. Он должен поддерживать определение данных и манипулирование ими, правила целостности, авторизацию и транзакции.

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

7. Вставка, обновление и удаление - СУБД поддерживает не только запрос данных, но и вставку, обновление и удаление.

8. Физическая независимость данных - Логика программ-приложений остается прежней при изменении физических методов доступа к данным и структур хранения.

9. Логическая независимость данных - Логика программ-приложений остается прежней, в пределах разумного, при изменении структур таблиц.

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

11. Независимость распределения - Запросы программ-приложений логически не затрагиваются при первом и последующих распределениях данных.

12. Несмешиваемость (может, кто-то знает более удачный перевод термина "Nonsubversion"?) - невозможность обойти ограничения целостности, используя языки низкого уровня.

К сожалению, оригинальных работ Кодда я не читал, но подобная портянка кочует из одного руководства в другое...

У Кодда кстати (говорят) действительно используются такие термины как кортеж и проекция.

>Ну я ораклист (10g сразу скажу - не видел), так вот покажи мне, где в 9 стало уж так плохо по-сравнению с 7 и 8, мм? Или опять треп?

Да всё очень просто те кто кричит что Oracle гавно никода ничё на нём не делали. Точнее так: перед ними никогда не вставала задачь под которые нужен был бы Oracle, ну не доросли ишо до них:) 10g тоже не видел но то что читал показалось очень вкусным MySQL до такого не вырасти никогда.

>Отзывы? :-) Т.е. сами то не щщупали, верно?

Ну я щупал и что? правда давненько года полтора как назад ну вообщем ничё примечательного я там неувидел. Может не очень искал? Хотя у меня была ситуация другая начальству стало интересно а чем бы можно заменить Oracle? Пока не заменили:))

Oracle естественно купленый так что радеющих за лицензионную чистоту софта просьба не беспокоиться:)

2 int19h
> Как утверждает мой лингво, "внешний ключ" переводится как
> "foreign key". И здесь я склонен с ним согласиться.
Потрясающий ответ! :) Ладно, проехали. Я тут, в общем-то, не собирался около научную дискуссию разворачивать... :))

> А что, нет? И вообще, обеспечивать уникальность кортежей
> в отношении - это даже мускуль умеет ;)
Т.е. кортеж без первичного ключа не вписывается в рамки реляционной модели?

Кстати, и при чём тут Мускуль?



2 pablott (*) (01.06.2004 2:01:48)
> У Кодда кстати (говорят) действительно используются такие
> термины как кортеж и проекция.
Кодд, кстати (говорят), действительно был математиком и во всех своих работах использовал математический аппарат... :) И его теоритическая работа получила такую популярность, как я понимаю, ещё и потому, что она была математически безупречна, что гарантировало отсутствие граблей (в мат. модели, что крайне важно) у тех, кто решится реализовать это "в железе".

2 no-dashi

> В основе реляционной модели лежит реляционная алгебра (раздел маетматики такой).

вы не совсем правы. реляционная алгебра (или другой подход, реляционное исчисление) это _операционная часть_ реляционной модели... а реляционная модель в целом состоит из трех частей:

1) структура данных (объекты)

2) целостность данных

3) обработка данных (операторы) - вот сюда и относится реляционная алгебра (или исчисление), как набор операций над _уже созданными_ объектами, т.е. в основе модели лежит прежде всего создание объектов + их целостность, а алгебра это уже потом начинается - выборка, проекция, соединение, деление и т.д.

> На уровне реализации.

нет. именно на уровне _теоретической модели_ вводится целостность

> Поддержание целостности - это функция СУБД, но не свойство модели данных.

это и свойство модели, и реализованная функция конкретной СУБД.

по крайней мере, так у Дэйта написано :)

2 int19h

А я уже не помню, что по этому поводу было у Дейта, и под рукой нет...

а у меня есть :) очень хороший учебник по теории БД... и еще кто-то Дэйта выше процитировал :) счас наверно но-даши скажет, что Дэйт это ацтой и ему надо в начальной школе пройти курс теории БД :)

> т.е. в основе модели лежит прежде всего
> создание объектов + их целостность

Может, всё же, просто множества + домены для аттрибутов?

> Oracle как был хорошей БД так в ближайшее время ей и останется и ни MySQl ни Postgre его не догонят никогда.

"Никогда" - это слишком долгий срок, чтобы делать на него прогнозы.