SQL *

Мы работаем над DWH в телекоммуникациях, поэтому пример, который я рассматриваю, называется «Абонент». Принцип универсален и это мог быть «Клиент» или «Пациент» — в зависимости от отрасли. Я надеюсь методику найдут полезной разработчики DWH из разных отраслей.

Если Вы не понимаете, что такое DWH, измерения и факты, я рекомендую прочитать книгу Ральфа Кимбалла «Dimensional Modeling». Речь идёт о базе данных для аналитики и консолидированной отчетности предприятия, конкретно о формировании и актуализации измерений — таблиц, которые хранят атрибуты (поля) для отбора (WHERE) в будущих запросах.

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

Дополнение к циклу переведенных статей.
Статьи: 1-3, 4-6, 7-9, 10-13, 14-15

Информация в статье относится к 5-й части руководства.

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

Введение.

Если отталкиваться от обывательской позиции человека, который разрабатывает базы данных, то внешние ключи – это удобно и упрощает жизнь (в большинстве случаев, всегда есть исключения.). Даже будучи невеждой в реляционной теории баз данных, к осознанной необходимости использования внешних ключей, на определенном этапе своего развития, приходит практически любой практик (утверждение — более относится к начинающим), который не стоит на месте в своем развитии и продолжает мыслить. Даже если он еще не знает, что то, что ему нужно называется связью по внешнему ключу, он начинает самостоятельно организовывать данные определенным образом, разбивать на отдельные таблицы и связывать их между собой. Настолько это становится очевидным.
Но при использовании внешних ключей, даже если не знать такого определения, возникает необходимость следить за связываемыми данными. Рассматриваемым объектом данной статьи является, если так можно сказать, своеобразный спутник, который следует за такой организацией данных. И в данном случае уже гораздо полезнее знать теорию, т.к. это может значительно упростить жизнь в процессе работы с базой данных.

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9, 10-13
Продолжение. Каскадное удаление данных.

14. Другой пример: база данных интернет-магазина.

Вы познакомились, я надеюсь, с основными концепциями создания баз данных и теперь вы можете спроектировать простую реляционную базу данных. В примере ниже я резюмирую задачи, с которыми вы столкнетесь при разработке базы данных.
P.S. Информация ниже в очень упрощенной форме моделирует мыслительный процесс при создании базы данных.

Система интернет-магазина.

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

• Отображение товаров
• Классификация товаров
• Регистрация клиентов
• Добавление товаров в корзину покупок
• Отображение содержимого корзины покупок
• Оформление заказов посетителями
• И т.д.

Определяем сущности и отношения.

Из списка задач мы можем вывести сущности, которые имеют важные роли в нашей системе. Товары, категории, клиенты и заказы – сущности, которые можно найти почти в каждой базе данных интернет-магазина. В данном примере я покажу вам модель, содержащую только следующие сущности: клиент, заказ и товар. Определившись с сущностями, мы можем подумать над связями между ними.

Продолжение.
Предыдущие части: 1-3, 4-6, 7-9

10. Нормализация баз данных

Указания для правильного проектирования реляционных баз данных изложены в реляционной модели данных. Они собраны в 5 групп, которые называются нормальными формами. Первая нормальная форма представляет самый низкий уровень нормализации баз данных. Пятый уровень представляет высший уровень нормализации.

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

Продолжение.
Предыдущие части: 1-3, 4-6

7. Связь один-ко-многим.

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

Другой пример связи один-ко-многим – это связь, которая существует между матерью и ее детьми. Мать может иметь множество детей, но каждый ребенок может иметь только одну мать.

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

Когда одна запись в таблице А может быть связана с 0, 1 или множеством записей в таблице B, вы имеете дело со связью один-ко-многим. В реляционной модели данных связь один-ко-многим использует две таблицы.


Схематическое представление связи один-ко-многим. Запись в таблице А имеет 0, 1 или множество ассоциированных ей записей в таблице B.

Выкладываю продолжение перевода цикла статей для новичков.
В настоящих и последующих — больше информации по существу.
Начало — здесь.

4. ТАБЛИЦЫ И ПЕРВИЧНЫЕ КЛЮЧИ

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



В таблице имеются 6 уроков. Все 6 – разные, но для каждого урока значения одинаковых полей хранятся в таблице, а именно: tutorial_id (идентификатор урока), title (заголовок)и category (категория). Tutorial_id – первичный ключ таблицы уроков. Первичный ключ – это значение, которое уникально для каждой записи в таблице.
В таблице клиентов ниже customer_id – первичный ключ. В данном случае первичный ключ – также уникальное значение (число) для каждой записи.

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

Другие части: 4-6, 7-9, 10-13, 14-15.

Руководство по проектированию баз данных.

1. Вступление.

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

Привет хабр! Приближается день программиста, и я спешу поделиться своими ненормальными наработками.

Японский кроссворд — NP-полная задача, как и задача коммивояжёра, укладки рюкзака и др. Когда ее решает человек, следует последовательно определять гарантированно заполненные и пустые ячейки. Одну за другой вычеркивать колонки и строки, пока не сложится весь рисунок. Как же возможно запрограммировать решение подобной задачи на языке, который официально даже не является языком программирования, не содержит циклов и переменных? SQL — язык запросов, его главная задача — выбирать строки. Вот мы и будем генерировать множество всех возможных перестановок и, словно скульптор, отсекать все лишнее.

Проблема постраничной выборки информации из БД стара, как сама БД, и соответственно, обсуждена не одну тысячу раз. Нет, пожалуй, ни одной клиент-серверной системы, в которой эта проблема так или иначе не была бы адресована и решена. Сегодня я хочу рассказать об одном немного нестандартном способе взаимодействия клиентского слоя и MS SQL-бакенда при организации постраничной выборки в типичном публичном веб-приложении.

Не найдя на хабре статьи, объединяющей в удобном для чтения виде информацию о методах доступа к данным, используемых СУБД Oracle, я решил совершить «пробу пера» и написать эту статью.

Общая информация

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

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

Недавно наткнулся на простое и эффективное решение одной элементарной даже не проблемы, а неудобства и решил поделиться. Суть вот в чем:

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

Естественно, многие из таких повторяющихся задач требуют различных специализированных «кусков кода», в зависимости от решаемой задачи  или БД. Оказалось, что часто быстрее и проще в поддержке не создавать множество однотипных, «почти» совпадающих скриптов SQL или версий, а применять «блочные комментарии» для временного выключения/включения нужного фрагмента SQL и вручную управлять ими в ISQL редакторе.

Для собственного удовольствия у меня на личном компьютере крутится робот для Википедии (аккаунт1, аккаунт2, исходный код). Бот держит локальный кеш версий страниц Википедии — чтобы не ходить каждый раз на удалённый сервер за ними, а также набор специфичных данных, которые собирались последние пару лет и очень важны для работы бота. Данные собираются в базу данных под управлением Apache Derby, и, вместе с кешем, БД занимает около 50 Гб.

И вот, в один прекрасный выходной день, когда бот обрабатывал данные в 8 потоков на 4-х CPU, Abbyy Finereader распознавал 14-ый том русского биографического словаря под редакцией А. А. Половцева, а противники делали свой ход в Civilization Age of Kings… возник он — синий экран смерти. Давненько не виделись, подумал я, перезагружая компьютер. С причиной ладно — скорее всего проблемы с видеоадаптером на аппаратной почве. Вот только когда компьютер загрузился и я попробовал запустить бота ещё раз, возникло это:

ERROR XSDG2: Invalid checksum on Page Page

А прошлый бэкап, как обычно, датирован мартом месяцем…

Июль уже подходит к концу, а на «хабре» до сих пор никто не вспомнил о CTP релизе MSSQL Server 2014.
Релизу будущего года присвоен позывной «Hekaton». Его появление было заявлено еще на конференции PASS 2012 года и тогда это было только название in-memory движка OLTP. Теперь это название целого релиза с встроенной поддержкой и оптимизацией обработки транзакций непосредственно в оперативной памяти.

Итак, дорогие хабровчане, хочу представить на ваше обозрение инструкцию, как нам пришлось поднимать OLAP-сервер в нашей компании. Шаг за шагом мы пройдем по пути, который был нами проделан, начиная с установки и настройки Pentaho и заканчивая подготовкой таблиц данных и публикацией olap-куба на сервере. Естественно, многое здесь может быть сумбурным/неточным/неоптимальным, но когда нам понадобилось поднять сервер и посмотреть, сможет ли Pentaho заменить нашу самописную статистику, у нас не было и такого…

Вступление

Некоторый интерес сообщества к моей первой статье, заставил меня усиленно поработать над orm. Мне еще не все в нем нравится (где-то код не оптимизирован; где-то реализация не такая, как я хотел; не хватает проверок и возможно стабильности), но он выполняет все необходимые в текущей момент мне функции. И так, встречайте: UcaOrm!

Рассмотрим ситуацию: имеется статистическая таблица с колонками-идентификаторами и колонками-счётчиками. Требуется просуммировать счётчики по некоторому подмножеству. При этом нас не интересует, каким образом мы выбираем интересующее нас множество — про индексы и партицирование написано множество книг и статей. Будем считать, что все данные уже выбраны самым оптимальным способом и изучим, как быстрее суммировать.

Это не первое место, которое надо оптимизировать, если запрос тормозит, скорее последнее. Изложенные ниже идеи осмысленно применять когда план выполнения (explain) уже с виду идеальный и комар в нём носа не подточит, но хочется «выжать» ещё немного.

Сразу оговорюсь, это не обучающий пост и не провозглашение новой парадигмы )), скорее решение, к которому я пришел, и хочется его обсудить в широкой и честной дискуссии.
Теперь к сути, представьте, что есть некая ORM, написанная на PHP, в которой описана модель Posts, имеющая связи многие-ко-многим через промежуточные таблицы с другими моделями: Comments, Tags, Categories. Вопрос в том, каким способом лучше поднимать связанные данные, всё сразу или с отложенной загрузкой?

Вступление

Идея написать свое приложение под Android пришла мне на пятый день отдыха в солнечном Таиланде. Не буду вдаваться в подробности что именно натолкнуло меня на неё, как и что я задумал за приложение (просто статья не об этом). Однако идея крепко укоренилась и на шестой день пребывания, воспользовавшись бесплатным интернетом в отеле, на ноутбук, взятый только ради просмотра фильмов и скидывания фотографий с фотоаппарата, я закачал MySql.
Начал я, как вы наверное уже догадались, с реляционный модели.
Работа шла трудно, но через пару месяцев с моделью я закончил и окунулся в дебри разработки под Android. До этого, под мобильные платформы я писал только на .Net Compact Framework, но так как с Java был знаком не понаслышке, накидать простенькую форму с кнопками труда не составило. Объектная модель, ожидаемо, трудностей не вызвала вообще и я, радостно предвкушая как сейчас мои тестовые данные улетят куда-то в недра устройства, открыл раздел Data Storage на сайте Android Developers. Раздел Using Databases нельзя назвать исчерпывающим, однако все необходимы ссылки на API он содержит, и я принялся писать своего наследника от SQLiteOpenHelper. После пары удачных проб, разбалованный Entity Framework’ом, я понял, что и тут бы было неплохо использовать какой-нибудь orm, так как сущностей у меня набралось больше десятка. Вбив в Великом и Ужасном «android orm», первую же ссылку я получил на эту статью, и несколько полезных на StackOverflow. Набрав в общей сложности три orm’а, я приступил к экспериментам.

Устали от однообразных браузерных игр, которые представляют собой лишь разные интерфейсы к базам данных? Встречайте mySQLgame — игру, которая представляет собой только базу данных.

Ощутите переполняющее чувство радости того, что вы вставляете свою собственную строку в таблицу «rows»!

При разумном выборе SQL-запросов вы вскоре получите трех- или даже четырехзначное число в одном из полей своей строки! На этот случай знайте: в игре идет самая настоящая война. В новых запросах вы сможете использовать эти числа для вычитания из строк других игроков — при этом номера в вашей собственной строке станут еще выше!