"Информатика. Учебное пособие для общеобразовательных учреждений с русским языком обучения", Г. А. Заборовский, А. Е. Пупцев
Проектирование базы данных — это подготовка её структуры до создания таблиц в СУБД. Сначала определяют, какие сведения нужны для решения задачи, затем выделяют типы объектов, их свойства и отношения между ними. Для каждого объекта выбирают ключ, который позволяет найти запись однозначно. Продуманная структура помогает хранить данные без лишних повторов, находить нужные сведения и выполнять запросы без потери смысла.
Текст подготовлен нейронной сетью по теме параграфа и не заменяет учебник — важные факты и формулировки сверяйте с ним.
Предметная область — часть реального мира, сведения о которой требуется хранить в базе данных. Например, для школьной библиотеки это книги, читатели и выдачи. Границы области определяют, какие объекты и факты включить, а какие не относятся к решаемой задаче.
Сущность — тип объектов предметной области, о которых собирают данные, например «Книга» или «Читатель». Отдельный экземпляр сущности — конкретный объект: книга с определённым названием или конкретный читатель. Такое различение нужно, чтобы описать общую структуру один раз, а не создавать её заново для каждого объекта.
Атрибут — характеристика сущности, представленная отдельным свойством или полем, например год издания у книги. Атрибуту задают имя, чтобы понимать смысл хранимого значения, и тип данных, чтобы ограничить его формат: текст, число или дата. Это помогает корректно вводить, искать и обрабатывать сведения.
Связь — отношение между сущностями, например между читателем и выданной ему книгой. Её вид и кратность определяют по правилам предметной области: одному объекту может соответствовать один, несколько или много объектов другой сущности. Это нужно, чтобы верно отразить реальные отношения в структуре базы.
Проектирование начинается с изучения задачи: нужно выяснить, кому предназначены данные, зачем они нужны и какие действия с ними будут выполнять. Например, библиотекарю может понадобиться узнать, какие книги выданы и кому их нужно вернуть. Если не выяснить эти потребности заранее, в структуре может не оказаться важных сведений или появятся лишние поля.
Затем из описания предметной области выделяют сущности и их атрибуты. Удобно искать существительные, обозначающие самостоятельные типы объектов, и отдельно — характеристики этих объектов. Если сведения повторяются или относятся к разным типам объектов, их часто следует хранить отдельно: тогда изменение данных не требует исправлять одно и то же во многих местах.
После этого устанавливают связи по правилам предметной области. Кратность показывает, скольким объектам одной сущности может соответствовать объект другой: например, один автор может написать несколько книг. Проверяя связь, важно задавать вопрос в обе стороны, потому что читатель может брать разные книги, а одну книгу могут выдавать разным читателям в разное время.
Для однозначного поиска каждой записи выбирают ключ — атрибут или набор атрибутов, значение которого различает экземпляры сущности. Фамилия может повторяться, а адрес или имя могут измениться, поэтому они ненадёжны как ключ. Уникальный номер личного дела подходит лучше: по нему можно найти конкретного ученика, не путая его с другими.
Инфологическое описание — схема объектов, свойств и отношений предметной области — затем превращают в структуру таблиц. Обычно сущность становится таблицей, атрибут — полем, а экземпляр — записью. Связи представляют средствами выбранной модели данных: при связи один ко многим достаточно связать таблицы ключами, а для связи многие ко многим обычно создают отдельную таблицу, чтобы не терять сведения о каждом отношении.
| Элемент | Смысл в предметной области | Представление в таблице |
|---|---|---|
| Сущность | Тип объектов, о которых хранят сведения | Таблица |
| Атрибут | Характеристика объекта | Поле |
| Экземпляр сущности | Отдельный объект данного типа | Запись |
| Ключ | Признак, однозначно определяющий объект | Поле или набор полей, уникальных для записи |
| Связь между сущностями | Отношение между объектами разных типов | Связанные ключи или отдельная таблица |
Используйте таблицу как переход от описания реальных объектов к структуре хранения. Для каждого типа объектов проверьте, какая таблица, запись и поля ему соответствуют. Способ представления связи уточняйте с учётом её кратности.
Условие. Для школьной библиотеки перечислите основные сущности и по два атрибута для каждой. Нужно отделить самостоятельные типы объектов от сведений, которые их описывают. Конкретные книги и люди будут экземплярами сущностей, а не отдельными сущностями.
Определим, какие объекты библиотека учитывает самостоятельно: книги и читателей. Это разные типы объектов, поэтому сведения о них не следует смешивать в одной таблице.
Для сущности «Книга» выберем атрибуты «Название» и «Год издания». Они характеризуют книгу, но сами по себе не являются отдельными объектами учёта.
Для сущности «Читатель» выберем атрибуты «Фамилия» и «Класс». Они описывают читателя; при дальнейшем проектировании можно добавить и другие нужные задаче свойства.
Ответ. Основные сущности: «Книга» с атрибутами «Название» и «Год издания»; «Читатель» с атрибутами «Фамилия» и «Класс». Если библиотеке нужно хранить выдачи, их тоже стоит рассмотреть как отдельный тип учитываемых фактов.
Условие. Для сущности «Ученик» даны атрибуты «Фамилия», «Имя» и «Номер личного дела». Нужно выбрать ключ и объяснить выбор. Проверим, позволяет ли значение атрибута отличить каждого ученика от всех остальных.
Фамилии могут совпадать у разных учеников, поэтому фамилия не гарантирует однозначную идентификацию. Имя тоже может повторяться, а сочетание имени и фамилии всё равно не обязательно уникально.
Номер личного дела присваивается для учёта конкретного ученика и должен быть уникальным. Он также меньше зависит от изменений личных сведений, чем имя или фамилия.
Сверим выбор с назначением ключа: по его значению должна находиться ровно одна запись. Если номера не повторяются и не меняются без необходимости, это подходящий ключ.
Ответ. Ключ — «Номер личного дела», поскольку он однозначно идентифицирует ученика. Фамилия и имя могут повторяться, поэтому использовать только их ненадёжно.
Условие. Читатель может брать разные книги, а книга — выдаваться разным читателям в разное время. Нужно определить сущности, атрибуты, ключи и связь. Одного перечня читателей и книг недостаточно: важно сохранить сведения о каждом факте выдачи.
Выделим сущности «Читатель» и «Книга». Для читателя зададим атрибуты «Номер читательского билета» и «Фамилия», для книги — «Инвентарный номер» и «Название»; номера будут ключами соответствующих таблиц.
Проверим кратность: один читатель может получить много книг, а одна книга может участвовать в выдачах разным читателям в разное время. Значит, между читателями и книгами возникает связь многие ко многим.
Создадим сущность «Выдача», потому что каждый случай связывает конкретного читателя с конкретной книгой в определённый момент. Её атрибутами могут быть номер билета, инвентарный номер и дата выдачи; для надёжной идентификации можно добавить отдельный номер выдачи.
Ответ. Нужны таблицы «Читатель», «Книга» и «Выдача». Таблица выдач связывает читателя и книгу и позволяет хранить отдельные события, в том числе повторную выдачу той же книги в другое время.
Сущность иногда принимают за отдельный объект: например, считают каждого ученика отдельной сущностью. Так структуру пришлось бы повторять для каждого человека, хотя достаточно описать тип «Ученик» и хранить объекты как записи. Проверьте себя: если объекты имеют общий набор характеристик, вероятно, это экземпляры одной сущности.
В одно поле могут записать несколько значений или объединить разные характеристики, например «фамилия, имя» одной строкой. Так поступают ради простоты ввода, но поиск по отдельному имени или сортировка усложняются. Проверьте, описывает ли каждое поле одно свойство и содержит ли запись одно значение этого свойства.
Ключом ошибочно выбирают атрибут, который может повторяться или меняться, например фамилию. Тогда нельзя надёжно отличить записи, а после изменения значения связи могут нарушиться. Представьте два одинаковых значения и возможное изменение данных: если идентификация перестаёт работать, атрибут не годится на ключ.
Считают, что любую связь можно выразить одним полем, хотя при связи многие ко многим это вызывает повторы и потерю отдельных случаев. Ошибка возникает, когда кратность не проверяют в обе стороны. Спросите, могут ли несколько объектов каждой сущности соответствовать одному объекту другой; если да, рассмотрите отдельную таблицу связи.
Для проектирования нужны базовые представления о базе данных, таблице, записи и поле, а также умение отличать объект от его свойств. Модель предметной области переводит описание задачи в понятную схему данных и подготавливает сведения к хранению в таблицах. Полученная структура используется при создании таблиц в СУБД, настройке ключей и связей, а затем — при составлении запросов. Поэтому ошибки в модели могут затруднить дальнейшую работу с данными.
Чем сущность отличается от экземпляра сущности?
Сущность — это тип объектов, например «Ученик», а экземпляр — конкретный объект этого типа, например ученик Иванов. В таблице сущности экземплярам обычно соответствуют отдельные записи.
Как понять, какие сведения выделить в отдельные атрибуты?
Каждый атрибут должен описывать одну характеристику сущности и хранить одно значение, например дату рождения или номер класса. Если сведения относятся к разным свойствам или повторяются списком, их обычно разделяют.
Почему фамилия обычно не подходит на роль ключа?
У разных людей могут быть одинаковые фамилии, поэтому по фамилии нельзя однозначно найти запись. Кроме того, фамилия может измениться; лучше использовать уникальный и устойчивый идентификатор.
Как определить кратность связи между сущностями?
Нужно выяснить по правилам предметной области, сколько объектов одной сущности может соответствовать одному объекту другой. Например, один ученик может посещать несколько кружков, а в кружке занимается много учеников — это связь «многие ко многим».
Зачем проектировать базу данных до создания таблиц в СУБД?
Предварительная модель помогает определить нужные таблицы, поля, ключи и связи, прежде чем вводить данные. Так проще избежать дублирования, противоречий и переделки структуры.
10.1. Проектирование базы данных
