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

Введение

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

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

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

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

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

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

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

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

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

Сущности предметной области

Совсем без терминов все-таки не получится. И самый важный для нас термин — это сущность предметной области. Иногда еще их называют информационными объектами, но мне больше нравится слово «сущность». Так что же это такое?

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

Реальные объекты, объединенные в одну сущность, будем называть экземплярами сущности.

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

Иван Иванович — хирург, врач высшей категории со стажем 25 лет. А Анастасия Павловна — терапевт, врач первой категории со стажем 2 года. Оба они совершенно конкретные живые люди, с которыми можно поговорить. И чтобы рассказать о них, мы назвали их имена, специальности, категории и стаж. Таких врачей, как они, в поликлинике почти сотня и всех их мы можем назвать одним словом «врач». Врач — это и будет то абстрактное понятие, которое объединяет конкретных Ивана Ивановича, Анастасию Павловну и других их коллег. «Имя», «Специальность», «Категория» и «Стаж» — это и есть одинаковые свойства, которыми описываются разные врачи.

Свойства, которыми описывается сущность, принято называть атрибутами сущности.

Итак, мы выделили сущность «Врач» с атрибутами «Имя», «Специальность», «Категория» и «Стаж». А Иван Иванович и Анастасия Павловна являются экземплярами сущности «Врач», для которых атрибуты принимают уже конкретные значения.

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

Самое трудное в проектировании увидеть эти самые сущности. Давайте продолжим тренироваться на примере поликлиники. С врачами разобрались. А «Пациент» — это сущность? Как это выяснить? Очень просто. Задаем два вопроса и отвечаем на них:

— Реальных пациентов в поликлинике много или один? — Много. Следовательно, «пациенты» являются группой объектов.

— Разные пациенты описываются одинаковыми свойствами? — Да. У всех пациентов есть «Фамилия», «Дата рождения», «Адрес».

Следовательно, понятие «Пациент» полностью соответствует определению сущности.

А является ли сущностью «Регистратура»? Снова задаем вопрос:

— Реальных регистратур в поликлинике много или одна? — Одна. Следовательно, «Регистратура» не является сущностью, потому что нет группы объектов. Второй вопрос можно уже не задавать.

А чем же тогда является «Регистратура»? Ведь такой объект в поликлинике есть, значит, он должен как-то отражаться в базе данных. Регистратура — это экземпляр сущности «Подразделение». Проверим эту гипотезу:

— Подразделений в поликлинике много? — Много. И регистратура — одно из них. А есть еще «Администрация», «Терапия», «Дневной стационар» и др. Следовательно, мы имеем группу объектов.

— Разные подразделения описываются одинаковыми свойствами? — Да. У каждого подразделения есть «Наименование», «Руководитель», «Номер телефона».

Следовательно, «Подразделение» — это сущность.

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

Связи между сущностями

Итак, в предметной области «Поликлиника» мы выделили пока три сущности:

— Врач.

— Пациент.

— Подразделение.

Для начала нам хватит.

В реальной жизни объекты предметной области взаимодействуют между собой. При проектировании факт взаимодействия отражается построением связей между сущностями. Связи между сущностями бывают трех типов:

— Связь «один-к-одному».

— Связь «один-ко-многим».

— Связь «много-ко-многим».

И на этом этапе несчастные студенты вынуждены заучивать нудное определение: «Связью типа „один-ко-многим“ называется связь, при которой одному экземпляру одной сущности соответствует много экземпляров другой сущности». Выучил? Молодец. А теперь пример. А в ответ тишина… Потому что практический смысл этого определения неясен.

Мы подойдем к проблеме чуть-чуть иначе. Для начала вспомним, что база данных — это модель реальности. Это значит, что само понятие «связь» можно увидеть где-то в реальной жизни. Где? Все просто. Возьмите любые две сущности и попробуйте описать словами русского языка их взаимодействие в формате

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

Итак,

Если у вас получилось построить такое предложение и оно звучит нормально и естественно, то связь есть. Только помните, что в одном предложении участвуют ровно две сущности!

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