| ← Ноябрь 2004 → | ||||||
|
2
|
3
|
4
|
5
|
6
|
||
|---|---|---|---|---|---|---|
|
8
|
9
|
10
|
11
|
12
|
13
|
|
|
15
|
16
|
17
|
18
|
19
|
20
|
|
|
22
|
23
|
24
|
25
|
26
|
28
|
|
|
29
|
30
|
|||||
За последние 60 дней ни разу не выходила
Сайт рассылки:
http://www.sql-ex.ru
Открыта:
15-09-2004
Статистика
0 за неделю
Новости сайта "Упражнения по SQL" (http://www.sql-ex.ru)
| Информационный Канал Subscribe.Ru |
Новости сайта "Упражнения по SQL" Выпуск 11 (28 ноября 2004 г.)
Новым посетителям сайтаСайт посвящен изучению языка, с помощью которого осуществляется взаимодействие с реляционными (и не только) СУБД. Суть обучения состоит в выполнении заданий на написание запросов к учебным базам данных; при этом система контролирует правильность выполнения заданий. В настоящее время реализованы все операторы подъязыка манипуляции данными (DML), которые включают в себя оператор извлечения данных SELECT, а также операторы модификации данных - INSERT, DELETE и UPDATE.Мы надеемся, что справочного материала сайта окажется достаточно для самостоятельного обучения. Кроме того, свои решения вы можете обсудить на форуме сайта. Опытных же специалистов приглашаем проверить (продемонстрировать) свое мастерство и принять участие в соревновании, обеспечиваемом рейтинговой системой учета времени выполнения заданий. Фактически, рейтинг ведется на втором этапе тестирования, который начинается после решения 62-х задач первого этапа. При подсчете рейтинга каждого участника отбрасывается один самый худший показатель среди всех решенных им упражнений. Имеется возможность заказать сертификат по SQL DML при выполнении определенного количества заданий. |
Новости сайта
§ По предложению edart стилистически улучшена формулировки задачи #31. Теперь она звучит так:
Для классов кораблей, калибр орудий которых не менее 16 дюймов, укажите класс и страну.
§ Формулировка задачи #24 допускала неоднозначность в понимании того, максимум по каждому типу продукции должен ли быть найден или же общий по всей продукции. Хотя выдаваемый "правильный" результат, на мой взгляд, не допускал неоднозначной трактовки, я по предложению Cyrilus решил уточнить формулировку этой задачи. Теперь она звучит так:
Перечислите номера моделей любых типов, имеющих самую высокую цену по всей имеющейся в базе данных продукции.
§ Опять прошло неверное решение для задачи #34. На этот раз у Sp999. Добавил данных.
Может конкурс объявить на то, кто найдет больше дырок в проверке? Пока, правда, без призового фонда. :-) Хотя может на это спонсор найдется?
§ Задачи #66 и #67 мало чем отличались. Однако после добавления новых данных под задачу #79 оказалось, что можно внести разнообразие в эти задачи, незначительно изменив формулировку одной из них. Ранее решения задач по одной и другой формулировкам давали один и тот же результат. Я изменил формулировку задачи 67. Решившие эту задачу ранее могут решить ее и в новой редакции.
§ На главной странице сайта можно увидеть текущую статистику дня: сколько людей заходило, сколько зарегистрировалось, сколько задач решено. Для нас это информация о развитии сайта, для вас - что вы не одиноки. :-)
§ На сайте появился новый рейтинг, названный "оптимистическим". Напомню, что один наихудший результат каждого участника отбрасывается при подсчете рейтинга ТОР 100. Однако участник рейтинговой системы, потерявший много времени уже на двух задачах, теряет шансы занять высокое место в рейтинге, даже если он опередит всех на других задачах. Этот недостаток существующей рейтинговой системы я решил исправить следующим образом.
Если результат, показанный участником на некоторой задаче превышает в N раз среднее время решения этой задачи по всем решившим ее, то такой результат заменяется этим средним временем. Тем самым как бы нивелируются "случайные выбросы". По умолчанию коэффициент N принимается равным 3. Ожидая дискусии по поводу выбора N, я решил сделать этот коэффициент параметром, который можно задавать на странице при запросе рейтинга. Собственно, рейтинг
потому и называется оптимистическим, что каждый может попробовать подобрать этот коэффициент таким образом, чтобы оказаться
как можно выше в рейтинге. Мои эксперименты показали, что это реально в определенных пределах. Успехов! :-)
§ Теперь можно посмотреть лучшие результаты показанные участниками на каждой задаче. Достаточно ввести номер задачи и нажать кнопочку. Данная возможность также находится в группе рейтингов, присутствующей на многих страницах сайта (фактически везде кроме страниц с упражнениями).
При этом я исключил "странные" результаты, т.е. результаты с очень быстрым временем решения. Полагаю, что эти результаты могли быть получены копированием чужих решений или своих, но под другим логином. Естественно, авторы задач исключены из списка "неблагонадежных".
Число участников рейтинга - 2278
Число участников второго этапа - 213
Лучшие результаты (ТОР 20)
| No | Surname | Number of Sel_ex |
Number of DML_ex |
Scores | Days | Days_2 | Last_Solved | Last_Visit |
| 1 | Зверев Д.Л. (dimzv) | 136 | 17 | 274 | 252.92 | 2.219 | 14 Jul 2004 | 14 Jul 2004 |
| 2 | Иткин И.Л. (joseph_itkin) | 136 | 17 | 274 | 245.84 | 2.792 | 29 Oct 2004 | 24 Nov 2004 |
| 3 | Якутин Н.В. (ZrenBy) | 136 | 6 | 274 | 428.80 | 3.993 | 24 Jun 2004 | 16 Nov 2004 |
| 4 | Леденев С.А. (Shurgenz) | 136 | 17 | 274 | 60.94 | 8.315 | 18 Oct 2004 | 27 Nov 2004 |
| 5 | Михайлов В.Г. (mslava) | 136 | 17 | 274 | 498.01 | 9.734 | 26 Oct 2004 | 26 Oct 2004 |
| 6 | Spirin (spirin) | 136 | 17 | 274 | 44.06 | 13.429 | 29 Sep 2004 | 29 Sep 2004 |
| 7 | Валуев Д.И. (Fiolent) | 136 | 17 | 274 | 293.15 | 19.314 | 23 Jun 2004 | 24 Nov 2004 |
| 8 | Мельникова И.А. (Iris_m) | 136 | 17 | 274 | 141.12 | 65.651 | 30 Sep 2004 | 25 Nov 2004 |
| 9 | Карабанов А. (gipa) | 133 | 0 | 268 | 138.58 | 5.022 | 10 Jul 2004 | 10 Jul 2004 |
| 10 | Новиков Д.А. (DimaN) | 130 | 0 | 264 | 68.17 | 2.104 | 01 Mar 2004 | 01 Mar 2004 |
| 11 | Драконов Ф.А. (f_d) | 130 | 0 | 264 | 36.32 | 7.243 | 03 Jun 2004 | 11 Nov 2004 |
| 12 | Пятница О.А. (Robin) | 128 | 17 | 259 | 589.55 | 70.834 | 06 Oct 2004 | 06 Oct 2004 |
| 13 | Губарь Д.К. (DEathkNIghtS) | 124 | 17 | 251 | 22.67 | 1.048 | 03 Nov 2004 | 03 Nov 2004 |
| 14 | Сныткин В.Л. (vlad_snt) | 124 | 17 | 251 | 83.07 | 4.508 | 24 Nov 2004 | 26 Nov 2004 |
| 15 | Смирнов А. (Leshich) | 124 | 17 | 251 | 147.15 | 84.180 | 03 Aug 2004 | 19 Nov 2004 |
| 16 | Ганя А.Д. (Sandman25) | 123 | 1 | 248 | 154.83 | 3.130 | 16 Jun 2004 | 16 Jun 2004 |
| 17 | сафрошкин В.Ю. (safervas) | 123 | 14 | 248 | 102.29 | 80.143 | 26 Nov 2004 | 26 Nov 2004 |
| 18 | Шулакова Н. (nshu) | 121 | 0 | 244 | 81.03 | 5.468 | 28 Feb 2004 | 28 Feb 2004 |
| 19 | Митронин А.А. (mitronin) | 120 | 9 | 241 | 405.96 | 2.150 | 09 Aug 2004 | 09 Aug 2004 |
| 20 | >Gershovich (VIG) | 120 | 17 | 241 | 626.03 | 4.056 | 27 Nov 2004 | 27 Nov 2004 |
Лучшие результаты за неделю
| No | surname | n_sel | sel_all | sel_scores | dml_scores | scores | rating | last_visit |
| 1 | Рассказов А. (ra) | 54 | 62 | 101 | 19 | 120 | 208 | 26 Nov 2004 |
| 2 | >Николаев А.Р. (AndrewN) | 56 | 56 | 94 | 9 | 103 | 255 | 27 Nov 2004 |
| 3 | >Пивоваров А.Г. (andreyp) | 51 | 51 | 86 | 9 | 95 | 296 | 27 Nov 2004 |
| 4 | >Кувалкин К.С. (Cyrilus) | 48 | 48 | 83 | 7 | 90 | 313 | 27 Nov 2004 |
| 5 | Галиаскаров Э.Г. (edart) | 53 | 53 | 85 | 0 | 85 | 305 | 26 Nov 2004 |
| 6 | Черемных В.П. (Sp999) | 41 | 41 | 60 | 9 | 69 | 458 | 27 Nov 2004 |
| 7 | Кузнецова А.А. (Nefertary) | 25 | 44 | 51 | 0 | 51 | 340 | 26 Nov 2004 |
| 8 | Порутчиков К.В. (3ABXO3) | 27 | 64 | 49 | 0 | 49 | 155 | 26 Nov 2004 |
| 9 | Иванов (chel_2000) | 31 | 31 | 44 | 3 | 47 | 594 | 26 Nov 2004 |
| 10 | Ponomarenko I. (ghost_i) | 26 | 26 | 43 | 1 | 44 | 600 | 26 Nov 2004 |
| 11 | Tsianovsky Z. (Zoycha) | 27 | 27 | 38 | 3 | 41 | 658 | 24 Nov 2004 |
| 12 | Илюшина А. (Ilyushina) | 13 | 61 | 31 | 9 | 40 | 227 | 26 Nov 2004 |
| 13 | Кузнецов М.В. (KuznetsovMV) | 21 | 21 | 30 | 9 | 39 | 863 | 23 Nov 2004 |
| 14 | Шимко И. (banga) | 15 | 42 | 28 | 9 | 37 | 418 | 26 Nov 2004 |
| 15 | shubin (lucas) | 20 | 26 | 37 | 0 | 37 | 608 | 26 Nov 2004 |
| 16 | Булаев В.В. (Kvix) | 15 | 79 | 36 | 0 | 36 | 75 | 26 Nov 2004 |
| 17 | >Korobkov G.N. (geo_life) | 23 | 24 | 36 | 0 | 36 | 704 | 27 Nov 2004 |
| 18 | Некрылов Д.В. (Mit) | 23 | 23 | 36 | 0 | 36 | 708 | 22 Nov 2004 |
| 19 | Minkin A. (angmin) | 23 | 23 | 34 | 0 | 34 | 733 | 23 Nov 2004 |
| 20 | Колосков А.В. (Pokemon) | 23 | 23 | 34 | 0 | 34 | 746 | 26 Nov 2004 |
| 21 | Campball (ACampball) | 21 | 21 | 29 | 5 | 34 | 872 | 21 Nov 2004 |
| 22 | Каменцев В.В. (vkamentcev) | 19 | 19 | 25 | 9 | 34 | 945 | 24 Nov 2004 |
| 23 | Bolschakoff (Bolschakoff) | 13 | 78 | 31 | 0 | 31 | 79 | 26 Nov 2004 |
| 24 | Бикчентаев Р.И. (KpNemo) | 22 | 22 | 31 | 0 | 31 | 807 | 23 Nov 2004 |
| 25 | >Шелевей И.С. (TMN) | 19 | 19 | 25 | 5 | 30 | 952 | 27 Nov 2004 |
Изучаем SQL
О неявном преобразовании типов в SQL Server 2000
Помимо типов данных в реляционной теории вводится фундаментальное понятие домена, как множества допустимых значений, которое может иметь атрибут. Можно сказать, что домен представляет собой пару {базовый тип данных, предикат}. При этом значение принадлежит домену только в том случае, если оно имеет соответствующий тип и предикат, вычисленный на этом значении, есть ИСТИНА. Атрибуты (столбцы таблицы) определяются на домене, т.е. помимо контроля типов СУБД при каждом изменении данных должна проверять также значение предиката. Изменение будет отклонено, если сохраняемое значение не удовлетворяет предикату домена.
Домен играет еще одну важную роль, а именно, сравниваться могут только значения, принадлежащие одному домену. Рассмотрим в качестве примера таблицу PC, а именно, столбцы speed (тактовая частота процессора) и hd (объем жесткого диска). Оба эти столбца имеют тип integer (или smallint). Однако это совершенно разные характеристики. Достаточно сказать, что в предметной области для них используются разные единицы измерения - герцы и байты. Так вот, если мы определим эти столбцы на разных доменах, то сравнение значения одного столбца со значением другого станет недопустимым. Причем контролироваться это будет СУБД. По аналогии с категорной и ссылочной целостностью такой контроль можно было бы назвать доменной целостностью, если бы этот термин не был занят в SQL Server под проверку ограничения CHECK, наложенного на столбцы таблицы. А так определенная "доменная целостность" никак не ограничивает сравнения.
Не лишним будет напомнить о важности поддержания целостности на стороне СУБД. Ограничения целостности, как правило, моделируют ограничения, реально существующие в предметной области. Поскольку эти ограничения не зависят от приложений, естественно их проверять (и писать) в месте, общем для всех приложений, которым и является СУБД. Это помимо прочего:
- избавляет приложения от необходимости встраивать (и дублировать!) в них необходимые проверки;
- гарантирует более высокий уровень безопасности. Ограничения, встроенные в приложения, легко обойти. Достаточно обратиться к базе данных, минуя приложение.
- облегчает сопровождение и разработку. Если ограничения предметной области изменятся, то соответствующие программные изменения нужно будет сделать в одном месте, а не во всех приложениях, работающих с базой данных.
Возвращаясь к доменам, уместно заметить, что и стандарт языка SQL 92 не вкладывает в понятие домена смысла "сравнимости". То, что реализовано стандартом, не более чем возможность один раз записать ограничения, а затем неоднократно применять их при определении спецификаций столбцов, т.е. возможность избежать дублирования кодов.
В цепочке "Теория - Стандарт - Реализация" последовательно теряется строгость реляционной теории, в результате чего мы не можем вполне прозрачно взаимодействовать с реляционными СУБД разных производителей.
Здесь же я хочу показать небольшой пример того, как следует обращаться с типами в SQL Server.
Итак, реально мы имеем то, что сравниваться могут значения одного типа. Для преобразования типов стандарт предлагает функцию CAST. Т.е. в общем случае мы должны преобразовать сравниваемые значения к одному типу, а затем уже выполнять операцию сравнения (или присвоения). Что же произойдет, если мы переменной (или столбцу) одного типа просто присвоим значение другого типа? Рассмотрим простой пример кода на T-SQL:
DECLARE @vc VARCHAR(10), @mn MONEY, @ft FLOAT
SELECT @vc = '499.99'
PRINT @vc
SELECT @ft = @vc
PRINT @ft
Здесь мы описывает три переменные соответственно строкового типа (VARCHAR), денежного типа (MONEY) и числа с плавающей точкой (FLOAT). Далее строковой переменной присваиваем константу соответствующего типа, а затем присваиваем переменной типа FLOAT значение строковой переменной. В результате получаем два одинаковых результата - 499.99 (оператор PRINT осуществляет вывод на консоль). То, что произошло, называется неявным преобразованием типов, т.е. строковое значение - '499.99' было автоматически приведено к типу FLOAT и присвоено переменной @ft.
Добавим в конец кода еще пару строк:
SELECT @mn = @vc
PRINT @mn
В результате получим два похожих сообщения об ошибке:
Implicit conversion from data type varchar to money is not allowed. Use the CONVERT function to run this query.
и
Implicit conversion from data type money to nvarchar is not allowed. Use the CONVERT function to run this query.
в одном из которых говорится о том, что неявное преобразование к типу money не допускается, а в другом - о недопустимости и обратного (к varchar) преобразования. Как и следовало ожидать, нам предлагается использовать явное преобразование с помощи функции COVERT. Однако чтобы быть ближе к стандарту, воспользуемся функцией CAST:
SELECT @mn=CAST(@vc AS MONEY) PRINT @mn
От первого сообщения об ошибке мы избавились. Напрашивается вывод о том, что второе сообщение дает оператор PRINT. Инстинкты подсказывают заглянуть в справку. В BOL об операторе PRINT говорится, что переменная, которая может использоваться в этом операторе, должна быть любого допустимого строкового типа ( char или varchar) или же должна неявно приводиться к этому типу.
Перепишем последнюю строку так
PRINT CAST(@mn AS VARCHAR)
Все работает. Главный вывод, который мы отсюда извлекаем, заключается в том, что не все типы (даже если мы не видим особых причин тому) допускают неявное преобразование.
В частности, не выполняется неявное приведение типа MONEY к типам CHAR, VARCHAR, NCHAR, NVARCHAR и наоборот.
А теперь о причине, которая заставила меня написать столь много слов. По моей неряшливости оказалось, что в основной и проверочной базе некоторые эквивалентные столбцы имели разные типы данных. Например, поле price в таблице РС имело тип FLOAT в одной базе и тип MONEY - в другой. В течение очень долгого времени это никак не влияло на работу сайта, но тут вдруг за последние несколько дней два наших участника решили использовать неявное преобразование типов в своих запросах с известным результатом. :-)
Я решил не ограничиваться извинениями, а написать опус об особенностях реализации, надеясь, что это принесет больше пользы, чем мои извинения.
Что же касается типов, то замеченное расхождение уже приведено в соответствие. На неделе обновлю скрипты для скачивания.
§ К сожалению, приведенные здесь примеры нельзя выполнить непосредственно на сайте. Это обусловлено тем, что пока мы не реализовали возможность исполнения наборов операторов (пакетов).
Поэтому тем, кто захочет проверить справедливость сказанного, придется воспользоваться Query Analyzer.
Контакты
По всем вопросам, связанным с функционированием сайта, проблемами при решении упражнений, идеями вы можете обращаться к Сергею И.Моисеенко msi77@yandex.ru. Вы также можете предложить свои задачи для публикации на сайте.
| http://subscribe.ru/
http://subscribe.ru/feedback/ |
Подписан адрес: Код этой рассылки: comp.soft.db.sqlex |
Отписаться |
| В избранное | ||
