Введение

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

Почему математика? Да потому, что базы данных – это чисто математический объект, который называется «реляционная алгебра». И тут, поверьте, есть от чего взорваться мозгу. В книге известного исследователя в области информационных технологий Джеффри Ульмана «Системы баз данных: полный курс» целых 1088 страниц. Проектированию на основе математического аппарата и описания реляционной алгебры посвящена примерно половина книги. Надо ли говорить, что студент второго курса обычно засыпает уже на десятой странице? А взрослый работающий человек, который хочет повысить свой скил по проектированию, просто отчаивается: «Когда я все это освою, если мне нужно уже через неделю спроектировать базу данных и показать результаты?!».

«Интуитивное» описание процесса проектирования намного проще, но оно не дает универсального подхода. Друзья, вот таблица, вот еще таблица. Эта штука называется первичный ключ. А в другой таблице есть столбец с таким же названием. Так вот их нужно соединить! Понятно? Понятно. Только вот, что делать, если у меня другая задача и другие таблицы? Кто вообще определяет, сколько у меня будет таблиц и что с чем соединять? Откуда в другой таблице взялся этот волшебный столбец? Что делать, если его там нет? На все эти вопросы «интуитивный» подход четкого ответа не дает. Он просто позволяет увидеть решение одной конкретной задачи.

Я проходила через все это сама, когда была студенткой на специальности «Прикладная математика». Я прохожу через это уже 18 лет с каждой новой группой моих студентов, которых я обучаю проектированию баз данных. На прочтение Ульмана у них просто нет ни времени, ни энтузиазма – им пять дисциплин сдавать в сессию. Да и, что тут греха таить, математика сразу вызывает стресс. А метод «я нашел в интернете» не позволяет спроектировать любую базу данных на все случаи жизни, то есть он не универсален.

За годы чтения курса баз данных на специальности «Прикладная информатика» я придумала методику проектирования, которая убивает двух зайцев сразу. С одной стороны совершенно не нужно продираться через несколько сотен страниц математики и падать в обморок от слов «кортеж», «алгебра», «нормальная форма», с другой стороны методика годится на все случаи жизни. Ну почти на все; -). Я даже рискну сказать ужасную для преподавателя вещь: если вы будете пользоваться этой методикой, вам не нужно будет думать, просто действуйте по алгоритму, и он сам приведет вас к результату. Ну что рискнем? Поехали!

Почему не нужно бояться баз данных?

Знаете почему не нужно бояться баз данных? Потому что в них нет ничего такого, чего нет в окружающем нас реальном мире. Вот смотрите, база данных проектируется для какой-то ограниченной части реального мира. Мы называем эту часть предметной областью. Например, «управление поликлиникой», «прием и отгрузка товара со склада», «управление кафе» – это все примеры предметных областей. База данных – это модель предметной области. А само слово «модель» означает, что допускаются определенные упрощения в сравнении с реальностью. В модели самолета нет таких деталей, которых нет в настоящем самолете. Наоборот, для упрощения некоторые детали в модели отсутствуют. Поэтому любая модель всегда будет проще реальности.

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

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