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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Рис.1 Сущность «Врач»

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

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

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

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

Рис.2 Сущность «Пациент»

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

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

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

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «ЛитРес».

Прочитайте эту книгу целиком, купив полную легальную версию на ЛитРес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.

Конец ознакомительного фрагмента

Купить и скачать всю книгу

На страницу:

Перейти

1 из 1