Здравствуйте, ttoorrmmoozz, Вы писали:
T>Вот готовлюсь к возможным казусам на интервью T>Поправьте меня там , где я неправ .
Думаю, что "казус" на интервью может случиться, если вы не определение правильно произнесёте, а не ответите на вопрос "зачем это, собственно нужно" или "как нормализовать структуру БД". Ещё каверзнее вопрос — "как денормализовать структуру, чтобы повысить, к примеру, производительность, и какие дополнительные усилия нужно приложить, чтобы сохранить целостность данных после денормализации".
Вот ответите на эти вопросы и, думаю, ни один нормальный интервьюер до вас не докопается...
Здравствуйте, ttoorrmmoozz, Вы писали:
T>Сегодня в одной уважаемой мной конторе я имел счастье собеседоваться. T>И там был поставлен следующий вопрос : T>вот имеются 2 копии одной и той же базы - T>одна нормализованная , другая нет . T>И далее сразу вопрос : какие селекты будут выполяться быстрее на T>ненормализованной копии ?
Постановка вопроса точно такая была? Может имелось в виду не "какие селекты", а "какие SQL-запросы"?
Денормализация выполняется в случаях, когда требуется увеличить производительность запросов выборки данных (select-запросов). Но при этом вырастают затраты на выполнение вставок, изменений и удалений.
Если же имелось в виду именно "какие селекты", то, в общем случае, лично я затрудняюсь ответить. Ответ можно дать только на конкретном примере денормализации. Допустим, мы нарушаем 3НФ и заводим таблицу с полями
T>Мдя — ну и формулировки на этой ссылке — свихнуться можно T>Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого. T>Я например нихрена не понял.
Это, кстати, к вопросу об образовании, который так часто тут обсуждается.
Если бы человек проучился хотя бы первый семестр первого курса, то мог бы воспринимать точные формулировки.
S>Показать себя человеком, подкованным в реляционной математике — это же круто!
В универе я понял одну простую вещь. Чтобы произвести благоприятное впечатление на преподавателя не обязательно хорошо знать предмет, но очень желательно уметь говорить на языке предмета. Если предмет разговора нормализация БД — то терминология одна, если SQL — терминология другая, и т.д.
Вот готовлюсь к возможным казусам на интервью
Поправьте меня там , где я неправ .
Говорят , что в теории баз данных существую5 форм нормализации .
Вроде каждая последующая является частным случаем предыдущей
1-я нормальная форма — Таблица представлена в первой нормальной форме (1НФ)
тогда и только тогда, когда все ее столбцы содержат только неделимые
значения и в ней отсутствуют повторяющиеся группы (столбцов) в пределах одной строки.Т.е. например столбик Фамилия_Имя_Отчество надо разбить на 3 столбика
2-я нормальная форма — это когда повторяющиеся значения в одном столбце
выносятся с помощью ключа в другую таблицу и в первой таблице уже идет
ссылка на id-шник из 2-й таблицы
3-я нормальная таблица — комбинация из повторяющихся значений может
быть вынесена с помощью ключа в отдельную таблицу
также невозможно удаление информации из базы
4-я нормальная форма — вот тут я не понял
5-я нормальная форма — это когда таблица не может далее разбиваться на более
мелкие таблицы посредством операции проектирования.
Так в чем вопрос-то?
Вот здесь вроде доходчиво: http://citforum.novgorod.net/database/dblearn/dblearn06.shtml
T>Вот готовлюсь к возможным казусам на интервью T>Поправьте меня там , где я неправ . T>Говорят , что в теории баз данных существую5 форм нормализации . T>Вроде каждая последующая является частным случаем предыдущей
T>1-я нормальная форма — Таблица представлена в первой нормальной форме (1НФ) T>тогда и только тогда, когда все ее столбцы содержат только неделимые T>значения и в ней отсутствуют повторяющиеся группы (столбцов) в пределах одной строки.Т.е. например столбик Фамилия_Имя_Отчество надо разбить на 3 столбика
T>2-я нормальная форма — это когда повторяющиеся значения в одном столбце T>выносятся с помощью ключа в другую таблицу и в первой таблице уже идет T>ссылка на id-шник из 2-й таблицы
T>3-я нормальная таблица — комбинация из повторяющихся значений может T>быть вынесена с помощью ключа в отдельную таблицу T>также невозможно удаление информации из базы
T>4-я нормальная форма — вот тут я не понял
T>5-я нормальная форма — это когда таблица не может далее разбиваться на более T> мелкие таблицы посредством операции проектирования.
Мдя — ну и формулировки на этой ссылке — свихнуться можно
Вот , например , определение 3НФ:
Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого.
Я например нихрена не понял.
Кстати , еще такой вопрос :
правильно ли сказано , что ссылочная целостность обеспечиается в основном
с помощью вторичного ключа ?
Здравствуйте, ttoorrmmoozz, Вы писали:
T>Мдя — ну и формулировки на этой ссылке — свихнуться можно
Нормальные формулировки.
T>Вот , например , определение 3НФ: T>Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого.
Ну во-первых это определение взаимно независимых атрибутов, а во-вторых вроде все правильно
T>Кстати , еще такой вопрос : T>правильно ли сказано , что ссылочная целостность обеспечиается в основном T>с помощью вторичного ключа ?
Хм, а ты сам то как себе это представляешь?
Возьмите книгу Дейта.
Там все более чем подробно описано.
Скажу честно, множественные зависимости (для 4 и 5 формы), как правило, плохо понимают даже "крутые перцы".
Здравствуйте, ttoorrmmoozz, Вы писали:
T>Мдя — ну и формулировки на этой ссылке — свихнуться можно T>Вот , например , определение 3НФ: T>Атрибуты называются взаимно независимыми, если ни один из них не является функционально зависимым от другого. T>Я например нихрена не понял.
Сие означает, что в таблице не должно быть полей, значения которых зависят от других полей. Например, в таблице есть поля:
Код счет-фактуры
Код товара
Название товара
В данном случае поле "Название товара" функционально зависит от поля "Код товара", 3НФ не выполняется.
T>Кстати , еще такой вопрос : T>правильно ли сказано , что ссылочная целостность обеспечиается в основном T>с помощью вторичного ключа ?
Не, ну так уж совсем криво. Правильней сказать "Ссылочная целостность между таблицами в большинстве случаев поддерживается с помощью внешних органичений (FOREIGN CONSTRAINTS)". Поле, по которому таблица связывается с первичным ключом другой таблицы, называется внешним ключом (FOREIGN KEY), а никак не вторичным ключом.
Да , я тоже имел в виду форейшн , просто обозвал его вторичным ключом .
Еще один момент про 3НФ : где-то я прочитал , что в базе , в которой выполняется 3НФ ,
невозможно удаление физической информации .
Т.е. хранение информации организована с помощью специальных дополнительных таблиц
верхнего абстрактного уровня , которые хранят в себе только ссылки и свззи на таблицы ,
в которых хранится реальная физическая информация .
И удаляются строки именно этих абстрактных таблиц , а реальная информация остается
Я прав ?
ttoorrmmoozz wrote: > > Еще один момент про 3НФ : где-то я прочитал , что в базе , в которой > выполняется 3НФ , > невозможно удаление физической информации . > Т.е. хранение информации организована с помощью специальных > дополнительных таблиц > верхнего абстрактного уровня , которые хранят в себе только ссылки и > свззи на таблицы , > в которых хранится реальная физическая информация . > И удаляются строки именно этих абстрактных таблиц , а реальная > информация остается
Чушь.
> Я прав ?
Тоже чушь. Не "прав — неправ", а "верно — неверно".
Здравствуйте, ttoorrmmoozz, Вы писали:
T>Да , я тоже имел в виду форейшн , просто обозвал его вторичным ключом .
Я так и понял. Однако, неправильные термины на интервью употреблять нельзя. Я бы, например, наверняка докопался.
T>Еще один момент про 3НФ : где-то я прочитал , что в базе , в которой выполняется 3НФ , T>невозможно удаление физической информации.
Никаких противопоказаний к удалению не существует. Бывают, впрочем, базы, данные в которых хранятся вечно. Потому что так надо.
T>Т.е. хранение информации организована с помощью специальных дополнительных таблиц T>верхнего абстрактного уровня , которые хранят в себе только ссылки и свззи на таблицы , T>в которых хранится реальная физическая информация . T>И удаляются строки именно этих абстрактных таблиц , а реальная информация остается
В базах, где данные хранятся вечно, записи не удаляются, а помечаются на удаление, и извлекаются запросами типа
select * from MyTable where isDeleted = 0
Часто для таких типовых запросов создают представления (VIEW). Подозреваю, что под "специальными дополнительными таблицами" как раз и подразумеваются представления. Если я правильно догадался, то имейте в виду, что представления — это не таблицы, ссылки и связи они не хранят.
Могу наврать, не занимался ьазами лет пять, память уже не та..
T>1-я нормальная форма — Таблица представлена в первой нормальной форме (1НФ) T>тогда и только тогда, когда все ее столбцы содержат только неделимые T>значения и в ней отсутствуют повторяющиеся группы (столбцов) в пределах одной строки.Т.е. например столбик Фамилия_Имя_Отчество надо разбить на 3 столбика
Все проще — данные представлены в виде двумерных отношений (таблиц), каждых аттрибут (поле) которых атомарен (т.е. не разбиваем на мелкие). Атомарность — понятие филосовское. Напри мер ИНН 18234567 для одного приложения атомарен, а для другого — нет (может разбит на код региона, номер, контрольную цифру, например я точно знаю что первые две цифры 18 говорят о том что ИНН выдан в Удмуртии)
T>2-я нормальная форма — это когда повторяющиеся значения в одном столбце T>выносятся с помощью ключа в другую таблицу и в первой таблице уже идет T>ссылка на id-шник из 2-й таблицы
Вы батенька совсем про другое — это факторизация. Вторая НФ говорит только о том, что все атрибуты зависят от первичного ключа. Зависят или нет — это тоже понятие филосовское, определяемое субъективно.
T>3-я нормальная таблица — комбинация из повторяющихся значений может T>быть вынесена с помощью ключа в отдельную таблицу T>также невозможно удаление информации из базы
Вы путаете следствие с причиной. Третья НФ — все атрибуты отношения зависят от первичного ключа нетранзитивно. Повторяются они или нет — пофиг.
Например
ИНН Фамилия №машины МодельМашины ТипКузова ЦветМашины
в данном случае ТипКузова и ЦветМашины зависят от ИНН транзитивно,
№машины зависит от того кто ее хозяин (а хозяин уникально идентифицируется
ИНН), а вот ТипКкузова и ЦветМашины — зависят скорее от ее номера (у машины с определенным номером — свой кузов и цвет)
Еще совет — освойте терминологию реляционной алгебры и реляционного исчисления, а то вы говорите на языке чайников. Нет в реляционной теории понятий "таблица","столбец","строка" — есть "отношение", "атрибут", "кортеж".
Здравствуйте, slskor, Вы писали:
T>>Да , я тоже имел в виду форейшн , просто обозвал его вторичным ключом . S>Я так и понял. Однако, неправильные термины на интервью употреблять нельзя. Я бы, например, наверняка докопался.
А к чему докапываться-то? Одно дело, знать что это делает и другое — знать как это называтся. Совсем другое дело — недорасказанность.
Здравствуйте, AntZ, Вы писали:
AZ>Еще совет — освойте терминологию реляционной алгебры и реляционного исчисления, а то вы говорите на языке чайников. Нет в реляционной теории понятий "таблица","столбец","строка" — есть "отношение", "атрибут", "кортеж".
Это не язык чайников. Данные понятия, если мне не изменяет память, введы sql server'ом.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, slskor, Вы писали:
T>>>Да , я тоже имел в виду форейшн , просто обозвал его вторичным ключом . S>>Я так и понял. Однако, неправильные термины на интервью употреблять нельзя. Я бы, например, наверняка докопался.
R3>А к чему докапываться-то? Одно дело, знать что это делает и другое — знать как это называтся. Совсем другое дело — недорасказанность.
Дело как раз в недорасказанности, в неточности. Докопался — это значит стал бы требовать рассказать детальнее о том, каким же образом вторичный ключ обеспечивает логическую целостность данных.
А вообще, имхо, термин "вторичный ключ" употребляется редко, поскольку не очен точен. Вторичный ключ можно перевести как secondary key, auxiliary key, в то время как единственно правильный перевод — foreign key. Но это мое личное мнение.
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, AntZ, Вы писали:
AZ>>Еще совет — освойте терминологию реляционной алгебры и реляционного исчисления, а то вы говорите на языке чайников. Нет в реляционной теории понятий "таблица","столбец","строка" — есть "отношение", "атрибут", "кортеж".
R3>Это не язык чайников. Данные понятия, если мне не изменяет память, введы sql server'ом.
Показать себя человеком, подкованным в реляционной математике — это же круто!
Здравствуйте, Real 3L0, Вы писали:
R3>Здравствуйте, AntZ, Вы писали:
AZ>>Еще совет — освойте терминологию реляционной алгебры и реляционного исчисления, а то вы говорите на языке чайников. Нет в реляционной теории понятий "таблица","столбец","строка" — есть "отношение", "атрибут", "кортеж".
R3>Это не язык чайников. Данные понятия, если мне не изменяет память, введы sql server'ом.
А нормализация я так понимаю тоже введена SQL сервером? Как это ни странно, большинство программистов БД знающих SQL совершенно не знают что такое реляционные алгебра/исчисление и почему большинство современных баз реляционные. Половина программеров не может ответить что выдаст
SELECT * FROM table1 t1, table1 t2
из оставшейся половины две трети не могут сказать что это такое.
(наиболее общий и универсальный вид JOIN — декартово произведение. Все остальные внутренние JOIN являются проекциями декартова произведения)
Программер который хорошо знает SQL но не понимает основ теории БД для меня является БД кодером. Очень сомневаюсь что сможет грамотно спроектировать серьезную БД.
Сегодня в одной уважаемой мной конторе я имел счастье собеседоваться.
И там был поставлен следующий вопрос :
вот имеются 2 копии одной и той же базы —
одна нормализованная , другая нет .
И далее сразу вопрос : какие селекты будут выполяться быстрее на
ненормализованной копии ?
S>А вообще, имхо, термин "вторичный ключ" употребляется редко, поскольку не очен точен. Вторичный ключ можно перевести как secondary key, auxiliary key, в то время как единственно правильный перевод — foreign key. Но это мое личное мнение.
Ты уверен, что это "единственно правильный перевод"?
Мне вот например, кажется, что secondary key называется так в противовес к primary key (логично, правда?)
То есть это ключ таблицы, который не является первичным.
AZ>Программер который хорошо знает SQL но не понимает основ теории БД для меня является БД кодером. Очень сомневаюсь что сможет грамотно спроектировать серьезную БД.
На самом деле я с трудом себе представляю программера, который хорошо знает SQL, но не понимает основ РСУБД.
Здравствуйте, Igor Trofimov, Вы писали:
S>>А вообще, имхо, термин "вторичный ключ" употребляется редко, поскольку не очен точен. Вторичный ключ можно перевести как secondary key, auxiliary key, в то время как единственно правильный перевод — foreign key. Но это мое личное мнение.
iT>Ты уверен, что это "единственно правильный перевод"?
iT>Мне вот например, кажется, что secondary key называется так в противовес к primary key (логично, правда?) iT>То есть это ключ таблицы, который не является первичным.
iT>Но это никак не foreign key
Это очень легко проверить. Откройте MSDN и поищите понятие secondary key. Его нет. А вот понятие foreign key constraint есть. То же самое — с хелпами по MS SQL Server. То же самое — с хелпами PowerDesigner. Я использовал англоязычную документацию по PostgreSQL, Oracle, Interbase и понятия secondary key не припомню. А если заглянуть в Free Online Dictionary of Computing (http://foldoc.doc.ic.ac.uk/foldoc/index.html), то становится вообще весело:
secondary key — A candidate key which is not selected as a primary key.
Alternate key — Any candidate key that is not the primary key. Also called a secondary key.
А теперь скажите, пожалуйста, имею ли я право докопаться до человека, утверждающего, что ссылочная целостность обеспечивается при помощи вторичных ключей и потребовать объяснений?
Русское понятие "вторичный ключ" сформировалось еще в советские времена. Я сам его употреблял, будучи студентом. Но это очень неточный и двусмысленный термин. Опытному программисту употреблять его не стоит.
Здравствуйте, Igor Trofimov, Вы писали:
AZ>>Программер который хорошо знает SQL но не понимает основ теории БД для меня является БД кодером. Очень сомневаюсь что сможет грамотно спроектировать серьезную БД.
iT>На самом деле я с трудом себе представляю программера, который хорошо знает SQL, но не понимает основ РСУБД.
Мое убеждение заключается в том, что на SQL можно научить "программировать" любого вменяемого человека. Программировать в кавычках, потому что запросы SQL к программированию имеют очень слабое отношение — это формализованный язык запросов типа "а выдай-ка мне всех женщин парашутисток за последние 20 лет у которых мужья программируют на SQL". SQL является способом сказать чего я хочу. Когда на FoxPro 2.0 появился кастрированный SQL то я очень успешно его использовал будучи полным нулем в реляционной теории.
Здравствуйте, ttoorrmmoozz, Вы писали:
T>Сегодня в одной уважаемой мной конторе я имел счастье собеседоваться. T>И там был поставлен следующий вопрос : T>вот имеются 2 копии одной и той же базы - T>одна нормализованная , другая нет . T>И далее сразу вопрос : какие селекты будут выполяться быстрее на T>ненормализованной копии ?
На первый взгляд, таких селектов должно быть подавляющее большинство. Нормализация, как известно, снижает скорость выполнения запросов.
Здравствуйте, AntZ, Вы писали:
.. AZ>А нормализация я так понимаю тоже введена SQL сервером? Как это ни странно, большинство программистов БД знающих SQL совершенно не знают что такое реляционные алгебра/исчисление и почему большинство современных баз реляционные. Половина программеров не может ответить что выдаст AZ>SELECT * FROM table1 t1, table1 t2 AZ>из оставшейся половины две трети не могут сказать что это такое.
Мне кажется, это не так. Я ни одного такого не знаю. Ну, м/б, некоторые не знают, как это называется.
Хотя! Знаю одного преподавателя с MSных курсов по SQL Server, который не знал, что декартово произведение м/б добыто таким способом. Но, опять-же, он предлагал легальный CROSS JOIN и это нельзя поставить ему в упрек.
AZ>(наиболее общий и универсальный вид JOIN — декартово произведение. Все остальные внутренние JOIN являются проекциями декартова произведения)
AZ>Программер который хорошо знает SQL но не понимает основ теории БД для меня является БД кодером. Очень сомневаюсь что сможет грамотно спроектировать серьезную БД.
Тут надо уточнить, что такое "основы теории БД", в данном контексте. Умение нормализовать данные — спец этому можно научить за пару дней. Человек может не знать слова "кортеж" и быть вполне вменяемым программистом БД и чувствовать себя в разработке, как рыба в воде. Лично я не помню определения всех нормальных форм — потому, что я ими (определениями) НЕ ПОЛЬЗУЮСЬ в повседневной работе.
Все это, кончено, не отменяет полезности теории — с академической точки зрения, во-первых и с позиции общей терминологии — для ведения дискуссии (опять-же, скорее академического характера).
S>Постановка вопроса точно такая была? Может имелось в виду не "какие селекты",
Да , вопрос был общим и звучал именно так :
какие селекты будут выполяться быстрее на ненормализованной копии ?
Т.е. я сам должен был привести конкретный вариант с разнесенной и неразнесенной таблицами и показать , что выборка в неразнесенном случае , о котором вы только что упомянули , будет работать быстрее .
Здравствуйте, ttoorrmmoozz, Вы писали:
T>какие селекты будут выполяться быстрее на ненормализованной копии ? T>Т.е. я сам должен был привести конкретный вариант с разнесенной и неразнесенной таблицами и показать , что выборка в неразнесенном случае , о котором вы только что упомянули , будет работать быстрее .
Я думаю что хотели, чтобы ты пример в пример дерево
S>А теперь скажите, пожалуйста, имею ли я право докопаться до человека, утверждающего, что ссылочная целостность обеспечивается при помощи вторичных ключей и потребовать объяснений?
ИМХО — безусловно. Но если вопрос исключительно в терминологии, да еще если и вам доводилось когда-то пользоваться этим же термином в этом же смысле — то (ИМХО, опять таки) не стоит из этого делать неутешительных выводов.
AZ>Когда на FoxPro 2.0 появился кастрированный SQL то я очень успешно его использовал будучи полным нулем в реляционной теории.
Пользоваться может и самый тупой студент. Вопрос о том, чтобы знать.
Т.е. понимать принципы работы и границы возможностей SQL и уметь их [принципы] применять для достижения нужного результата в рамках этих возможностей.
Приведенный выше пример
SELECT * FROM TABLE12, TABLE2
обычно очень наглядно показывает разницу между "умеющим использовать" и "знающим". Хорошо также идут примитивные запросы с группировкой или внешними соединениями.
Здравствуйте, Igor Trofimov, Вы писали:
S>>А теперь скажите, пожалуйста, имею ли я право докопаться до человека, утверждающего, что ссылочная целостность обеспечивается при помощи вторичных ключей и потребовать объяснений?
iT>ИМХО — безусловно. Но если вопрос исключительно в терминологии, да еще если и вам доводилось когда-то пользоваться этим же термином в этом же смысле — то (ИМХО, опять таки) не стоит из этого делать неутешительных выводов.
Поскольку русскоязычный термин "вторичный ключ" таки имеет хождение и если человек все правильно объяснит, то вопрос исчерпан, нет проблем.
Как еще один пример "разночтений", который немного мешает в жизни, можно привести русский вариант термина Use-case diagram. В книгах переводы "Диаграмма прецедентов" и "Диаграмма вариантов использования" встречаются 50/50. С некоторых пор, дабы не бодаться с коллегами, предпочитаю использовать оригинальный, английский термин.
Здравствуйте, Igor Trofimov, Вы писали:
AZ>>Когда на FoxPro 2.0 появился кастрированный SQL то я очень успешно его использовал будучи полным нулем в реляционной теории.
iT>Пользоваться может и самый тупой студент. Вопрос о том, чтобы знать. iT>Т.е. понимать принципы работы и границы возможностей SQL и уметь их [принципы] применять для достижения нужного результата в рамках этих возможностей.
iT>Приведенный выше пример
SELECT * FROM TABLE12, TABLE2
обычно очень наглядно показывает разницу между "умеющим использовать" и "знающим". Хорошо также идут примитивные запросы с группировкой или внешними соединениями.
Еще один простой, но достаточно пакостный вопрос на интервью — по использованию having
