Основы правил проектирования базы данных

Содержание

Литература

  • Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4.
  • Когаловский М.Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. — 288 с. — ISBN 5-279-02276-4.
  • Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
  • Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2.
  • Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: «Вильямс», 2003. — 1436 с. — ISBN 0-201-70857-4.
  • Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. — М.: «Вильямс», 2003. — 1088 с. — ISBN 5-8459-0384-X.

Литература

  • Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4.
  • Когаловский М.Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. — 288 с. — ISBN 5-279-02276-4.
  • Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
  • Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2.
  • Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: «Вильямс», 2003. — 1436 с. — ISBN 0-201-70857-4.
  • Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. — М.: «Вильямс», 2003. — 1088 с. — ISBN 5-8459-0384-X.

Типы отношений

В каждом отношении может присутствовать две и более сущностей, и в зависимости от количества сущностей отношения между ними могут описываться как бинарные (binary), тернарные (ternary), кватернарные (quaternary) и т.д. В реальной жизни чаще всего встречаются отношения бинарного типа, поэтому давайте остановимся на них более подробно.


Мощность (cardinality), или количество элементов, отношения показывает, сколько экземпляров одной сущности может соотноситься с экземпляром другой сущности. Тот факт, что бинарное отношение отражает взаимоотношения между двумя сущностями, вовсе не означает, что между ними всегда существует отношение типа “один к одному”.

Отношения между сущностями могут представлять собой и отношения типа “один к од- ному”, и “один ко многим”, и “многие ко многим” или отношения еще какого-то другого типа. Чаще всего встречаются отношения следующих типов (при условии наличия двух сущностей, A и B).

  • Один ко многим. В таких отношениях каждый экземпляр сущности A может иметь отношение с несколькими членами другой сущности B. Например, сущность под названием Клиент может брать много книг из библиотеки, но каждая книга за раз может выдаваться только одному единственному Клиенту. Соответственно получается, что между сущностями Клиент и Книга должно существовать отношение типа “один ко многим”. Разумеется, такое отношение может и не существовать при наличии Клиента, который еще не брал никакой Книги. То есть фактически отношение должно гласить следующее: “один Клиент может брать ноль, одну или более Книг”.
  • Один к одному. В таких отношениях только один экземпляр любой из сущностей может иметь отношение с экземпляром другой сущности. Например, у каждого человека может быть только один действительный номер карточки социального страхования (Social Security Number — SSN), а каждый номер карточки социального страхования может ссылаться только на одного человека.
  • Многие ко многим. В таких отношениях каждый экземпляр сущности A может иметь отношение с одним и более экземплярами сущности B, а каждый экземпляр сущности B — с одним и более экземплярами сущности A. В качестве примера возьмем сущность под названием Кинозвезда и сущность под названием Кинофильм. Каждая кинозвезда может сниматься в нескольких Кинофильмах, и в каждом Кинофильме может принимать участие несколько Кинозвезд. В реальной жизни отношения типа “многие ко многим” обычно разбиваются на более простые отношения типа “один ко многим”, которые, как сложилось, являются наиболее распространенной формой отношений между сущностями.

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

Выбор системы управления и программных средств БД

От выбора системы управления БД зависит практическая реализация информационной системы. Наиболее значимыми критериями в процессе выбора становятся параметры:

  • типа модели данных и её соответствие потребностям предметной области,
  • запас возможностей в случае расширения информационной системы,
  • характеристики производительности выбранной системы,
  • эксплуатационная надёжность и удобство СУБД,
  • инструментальная оснащённость, ориентированная на персонал администрирования данных,
  • стоимость самой СУБД и дополнительного софта.

Ошибки в выборе СУБД практически наверняка впоследствии спровоцируют необходимость корректировать концептуальную и логическую модели.

Основные этапы проектирования баз данных

Концептуальное (инфологическое) проектирование

Пример концептуальной схемы

Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

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

Чаще всего концептуальная модель базы данных включает в себя:

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

Логическое (даталогическое) проектирование

Пример логической схемы для реляционной модели данных.

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

Физическое проектирование

Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. д.

Результатом физического проектирования логической схемы выше на языке SQL может являться следующий скрипт:

CREATE TABLE IF NOT EXISTS Department ( -- Факультет
  id INT NOT NULL,
  name VARCHAR(45),
  PRIMARY KEY (id)
);

CREATE TABLE IF NOT EXISTS Group (
  id INT NOT NULL,
  name VARCHAR(45) ,
  depart_id INT NOT NULL,
  UNIQUE INDEX depart_id_UNIQUE (depart_id ASC),
  PRIMARY KEY (id, depart_id),
  CONSTRAINT depart_fk
    FOREIGN KEY (depart_id)
    REFERENCES Department (id)
);

CREATE TABLE IF NOT EXISTS Student (
  first_name VARCHAR(16) NOT NULL,
  last_name VARCHAR(45) NOT NULL,
  email VARCHAR(255),
  group_id INT NOT NULL,
  PRIMARY KEY (last_name, first_name, group_id),
  INDEX group_fk_idx (group_id ASC),
  CONSTRAINT group_fk
    FOREIGN KEY (group_id) REFERENCES Group (id)
);

Основы правил проектирования

  1. отношение многие к одному: Эту связь можно рассмотреть зеркально к приведенной выше связи один ко многим. Иными словами, отношение сущности «дети» к сущности «родители», где обязательная связь будет при условии, что у ребенка есть хотя бы один родитель. Если же участвуют все дети, в том числе и находящиеся в детских домах, отношение будет с необязательной связью.

один ко многиммногие к одному

  1. п.1 (п.1.1 и п.1.2) — первое и второе формальные правила
  2. п.2 (п.2.1 и п.2.2) — третье и четвертое формальные правила
  3. п.3 (аналогично п.2) — пятое и шестое формальные правила
  4. п.4 — седьмое формальное правило

нормализацииденормализацияодин к одномуодному ко многиммногие к одномумногие ко многим

  • Когда семья была полной, с несколькими детьми, отношение между родителями и детьми имело вид многие ко многим.
  • Когда остались мать и дети, отношение между родителем и детьми стало один ко многим с обязательной связью. Однако, в любой семье, где может и не быть детей, это отношение будет таким же, но уже с необязательной связью.
  • А вот со стороны детей отношение к родителю было как многие к одному с обязательной связью пока родителя не лишили родительских прав.
  • Когда дети оказались в детском доме — отношение изменилось на многие к одному с необязательной связью.
  • Когда у детей появились попечители, связь между ними стала многие ко многим: у каждого попечителя могут быть другие подопечные дети, а у каждого ребенка могут быть другие попечители (родители).

один к одному с обязательной связьюодин к одному с необязательной связьюодин ко многиммногие к одномуодин к одному с обязательной связьюодин к одному с необязательной связьюВажно запомнить

Надежный выбор лидера в Tarantool Cartridge

Сегодня я немного расскажу о том, какие есть мысли по поводу фейловера в tarantool/cartridge. Сначала пару слов про то, что такое cartridge: это кусок lua-кода, который работает внутри tarantool и объединяет тарантулы друг с другом в один условный «кластер». Это происходит за счет двух вещей:

  • каждый тарантул знает сетевые адреса всех других тарантулов;
  • тарантулы регулярно «пингуют» друг друга через UDP, чтобы понять кто жив, а кто нет. Тут я намеренно немного упрощаю, алгоритм пинга сложнее чем просто request-response, но это для разбора не сильно принципиально. Если интересно — погуглите алгоритм SWIM.

Внутри кластера все обычно разделяется на тарантулы «с состоянием» (master/replica) и «без состояния» (router). Тарантулы «с состоянием» ответственны за хранение данных, а тарантулы «без состояния» — за маршрутизацию запросов.

PostgreSQL Antipatterns: уникальные идентификаторы

Достаточно часто у разработчика возникает потребность формировать для записей таблицы PostgreSQL некие уникальные идентификаторы — как при вставке записей, так и при их чтении.

Таблица счетчиков

Казалось бы — чего проще? Заводим отдельную табличку, в ней — запись со счетчиком. Надо получить новый идентификатор — читаем оттуда, чтобы записать новое значение — делаем … Так делать не надо! Потому что завтра же вам придется решать проблемы:

  • постоянных пересекающихся блокировок при см. PostgreSQL Antipatterns: сражаемся с ордами «мертвецов»
  • постепенной деградации скорости доступа к данным таблицы счетчиков см. PostgreSQL Antipatterns: обновляем большую таблицу под нагрузкой
  • … и необходимости ее зачистки при активных транзакциях, которые будут вам мешать см. DBA: когда пасует VACUUM — чистим таблицу вручную

Основы правил проектирования базы данных

Tutorial

Введение

Как это часто бывает, архитектору БД нужно разработать базу данных под конкретное решение. Однажды в пятницу вечером, возвращаясь на электричке домой с работы, подумал, как бы я создал сервис по найму сотрудников в разные компании. Ведь ни один из существующих сервисов не позволяет быстро понять насколько подходит тебе кандидат, нельзя создать сложные фильтры именно по конкретным навыкам, проектам и позициям или исключающие определенные навыки, позиции и проекты. Максимум, что предлагают сервисы — это фильтры по компаниям и частично по навыкам. В данной статье я позволю себе немного разбавить строгое техническое изложение материала, размешав техническую информацию не техническими примерами из жизни. В данном примере разберем создание базы данных в MS SQL Server для сервиса поиска соискателей на работу. Также данный материал можно перенести и на другую СУБД такую как MySQL или PostgreSQL.

Установите для себя правила именования таблиц и полей

Сложно работать с данными, которые выглядят как-то так: , , . Конечно, каждый программист в праве сам выбирать для себя стиль наименования, но для SQL рекомендуется выбрать наименование с подчёркиванием. Потому что не все SQL-движки одинаково работают с заглавными буквами, а помещать всё в кавычки бывает утомительно.

Ещё нужно определиться как будут называться таблицы — во множественном числе () или в единственном (). Каждая базовая структура в БД обычно настроена на множественное число, поэтому и именовать таблицы стоит соответственно.


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

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

Основные этапы проектирования баз данных

Концептуальное (инфологическое) проектирование

Пример концептуальной схемы

Концептуальное (инфологическое) проектирование — построение семантической модели предметной области, то есть информационной модели наиболее высокого уровня абстракции. Такая модель создаётся без ориентации на какую-либо конкретную СУБД и модель данных. Термины «семантическая модель», «концептуальная модель» и «инфологическая модель» являются синонимами. Кроме того, в этом контексте равноправно могут использоваться слова «модель базы данных» и «модель предметной области» (например, «концептуальная модель базы данных» и «концептуальная модель предметной области»), поскольку такая модель является как образом реальности, так и образом проектируемой базы данных для этой реальности.

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

Чаще всего концептуальная модель базы данных включает в себя:

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

Логическое (даталогическое) проектирование

Пример логической схемы для реляционной модели данных.

Логическое (даталогическое) проектирование — создание схемы базы данных на основе конкретной модели данных, например, реляционной модели данных. Для реляционной модели данных даталогическая модель — набор схем отношений, обычно с указанием первичных ключей, а также «связей» между отношениями, представляющих собой внешние ключи.

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

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

Физическое проектирование

Физическое проектирование — создание схемы базы данных для конкретной СУБД. Специфика конкретной СУБД может включать в себя ограничения на именование объектов базы данных, ограничения на поддерживаемые типы данных и т. п. Кроме того, специфика конкретной СУБД при физическом проектировании включает выбор решений, связанных с физической средой хранения данных (выбор методов управления дисковой памятью, разделение БД по файлам и устройствам, методов доступа к данным), создание индексов и т. д.

Результатом физического проектирования логической схемы выше на языке SQL может являться следующий скрипт:

CREATE TABLE IF NOT EXISTS Department ( -- Факультет
  id INT NOT NULL,
  name VARCHAR(45),
  PRIMARY KEY (id)
);

CREATE TABLE IF NOT EXISTS Group (
  id INT NOT NULL,
  name VARCHAR(45) ,
  depart_id INT NOT NULL,
  UNIQUE INDEX depart_id_UNIQUE (depart_id ASC),
  PRIMARY KEY (id, depart_id),
  CONSTRAINT depart_fk
    FOREIGN KEY (depart_id)
    REFERENCES Department (id)
);

CREATE TABLE IF NOT EXISTS Student (
  first_name VARCHAR(16) NOT NULL,
  last_name VARCHAR(45) NOT NULL,
  email VARCHAR(255),
  group_id INT NOT NULL,
  PRIMARY KEY (last_name, first_name, group_id),
  INDEX group_fk_idx (group_id ASC),
  CONSTRAINT group_fk
    FOREIGN KEY (group_id) REFERENCES Group (id)
);

Несколько SQL-приемов от Application DBA. Нетривиальные особенности работы с базами данных

Перевод

Свою карьеру в области разработки я начал с позиции администратора баз данных, DBA, и в то время, еще до AWS RDS, Azure, Google Cloud и прочих облачных сервисов, DBA делились на два типа:Infrastructure DBA отвечал за настройку баз данных, конфигурацию хранилищ, работу с резервным копированием и восстановлением. После настройки базы данных Infrastructure DBA появлялся лишь изредка и «донастраивал инстансы», например корректировал размер кэшей.Application DBA получал в свои руки чистую, только что настроенную базу данных от Infrastructure DBA и отвечал за дизайн схемы: создание таблиц, индексов, ограничений и донастройку SQL. ETL процессы и миграция данных тоже ложилась на плечи Application DBA, равно как и хранимые процедуры (если ими пользовались). Обычно Application DBA состояли в команде разработчиков, и зачастую из-за необходимости глубоко понимать все тонкости проекта они работали всего над одним или двумя, тогда как Infrastructure DBA сидели в какой-нибудь IT команде и работали сразу над несколькими проектами.Моя должность — Application DBA

Используйте хотя бы третью нормальную форму

Нормальные формы — это требования, которые должны соблюдаться при правильной проектировке базы данных.

Вебинар «Производительность 1С на PostgreSQL в Яндекс.Облаке»

27 августа в 12:00 в 12:00, онлайн, беcплатно

tproger.ru

События и курсы на tproger.ru

Нормальных форм существует целых 6 штук, однако обычно соблюдают всего лишь 3 и для начала этого более чем достаточно.

Первая нормальная форма

Для примера будем использовать отношение сотрудники_отделы_проекты. В нём есть информация о номере сотрудника, его фамилии, номере отдела, в котором он работает, номере телефона отдела и так далее.

Это отношение, как и любое другое, автоматически находится в первой нормальной форме:

  • в отношении нет одинаковых кортежей;
  • кортежи не упорядочены;
  • атрибуты не упорядочены и различаются по наименованию;
  • все значения атрибутов атомарны.

Вторая нормальная форма

В нашем случае у таблицы выше имеется сложный (составной) ключ . От части ключа зависят неключевые атрибуты , , . От части ключа зависит неключевой атрибут . А вот атрибут зависит от всего составного ключа, так как сотрудник может выполнять одно задание в одном проекте.

Поэтому для приведения отношения ко второй нормальной форме из отношения сотрудники_отделы_проекты нужно выделить два отношения сотрудники_отделы и проекты, а исходное отношение оставим отношением задания.

Наконец, третья нормальная форма


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

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

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

Литература

  • Дейт К. Дж. Введение в системы баз данных = Introduction to Database Systems. — 8-е изд. — М.: «Вильямс», 2006. — 1328 с. — ISBN 0-321-19784-4.
  • Когаловский М.Р. Перспективные технологии информационных систем. — М.: ДМК Пресс; Компания АйТи, 2003. — 288 с. — ISBN 5-279-02276-4.
  • Когаловский М.Р. Энциклопедия технологий баз данных. — М.: Финансы и статистика, 2002. — 800 с. — ISBN 5-279-02276-4.
  • Кузнецов С. Д. Основы баз данных. — 2-е изд. — М.: Интернет-Университет Информационных Технологий; БИНОМ. Лаборатория знаний, 2007. — 484 с. — ISBN 978-5-94774-736-2.
  • Коннолли Т., Бегг К. Базы данных. Проектирование, реализация и сопровождение. Теория и практика = Database Systems: A Practical Approach to Design, Implementation, and Management. — 3-е изд. — М.: «Вильямс», 2003. — 1436 с. — ISBN 0-201-70857-4.
  • Гарсиа-Молина Г., Ульман Дж., Уидом Дж. Системы баз данных. Полный курс. — М.: «Вильямс», 2003. — 1088 с. — ISBN 5-8459-0384-X.

Модели «сущность-связь»

Основная статья: ER-модель данных

Модель «сущность-связь» (англ. “Entity-Relationship model”), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма, либо с использованием других графических нотаций (Crow’s Foot, Information Engineering и др.).

Основные преимущества ER-моделей:

  • наглядность;
  • модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
  • ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

  • объекты (сущности);
  • атрибуты объектов;
  • связи между объектами.

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

Связь между сущностями характеризуется:

  • типом связи (1:1, 1:N, N:М);
  • классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности — обязательный, иначе — необязательный.

Используйте проверочные ограничения

База данных — это не просто набор таблиц. В неё встроено много инструментов, которые помогут с сохранностью и качеством данных.

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

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

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

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

Используйте , чтобы убедиться, что значения входят в диапазон (например чтобы цена не была отрицательной).

Проектирование схемы базы данных для поиска соискателей на работу

  1. для HR: 1.1) компании, где работал соискатель 1.2) позиции, которые ранее занимал соискатель в данных компаниях 1.3) навыки и умения, которыми соискатель пользовался в работе; а также продолжительность работы соискателя в каждой компании на каждой позиции и длительность использования каждого навыка и умения
  2. для технического специалиста: 2.1) позиции, которые занимал соискатель в данных компаниях 2.2) навыки и умения, которыми соискатель пользовался в работе 2.3) проекты, в которых участвовал соискатель; а также продолжительность работы соискателя на каждой позиции и в каждом проекте, длительность использования каждого навыка и умения
  1. Сотрудник (Employee)
  2. Компания (Company)
  3. Позиция (должность) (Position)
  4. Проект (Project)
  5. Навык (Skill)
  • Компании и сотрудники относятся как многие ко многим, так как сотрудник мог работать в нескольких компаниях, а в компании работают многие люди.
  • Аналогично относятся позиции и сотрудники: несколько сотрудников могут занимать одну позицию как в рамках как одной, так и нескольких компаний.
  • С другой стороны, сотрудник мог работать на разных позициях как в рамках одной, так разных компаний. Таким образом, отношение между позициями и компаниями — многие ко многим.
  • Аналогично и по проектам: проекты относятся ко всем выше рассмотренным сущностям как многие ко многим.
  • Для простоты будем считать, что в проекте сотрудник использует один набор навыков.
  • Тогда проекты и навык относятся как многие ко многим.

Рис.11. Схема базы данных для поиска соискателей на работумногие ко многиммногие ко многим

Модели «сущность-связь»

Модель «сущность-связь» (англ. “Entity-Relationship model”), или ER-модель, предложенная П. Ченом в 1976 г., является наиболее известным представителем класса семантических (концептуальных, инфологических) моделей предметной области. ER-модель обычно представляется в графической форме, с использованием оригинальной нотации П. Чена, называемой ER-диаграмма, либо с использованием других графических нотаций (Crow’s Foot, Information Engineering и др.).

Основные преимущества ER-моделей:

  • наглядность;
  • модели позволяют проектировать базы данных с большим количеством объектов и атрибутов;
  • ER-модели реализованы во многих системах автоматизированного проектирования баз данных (например, ERWin).

Основные элементы ER-моделей:

  • объекты (сущности);
  • атрибуты объектов;
  • связи между объектами.

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

Связь между сущностями характеризуется:

  • типом связи (1:1, 1:N, N:М);
  • классом принадлежности. Класс может быть обязательным и необязательным. Если каждый экземпляр сущности участвует в связи, то класс принадлежности — обязательный, иначе — необязательный.

Физическое проектирование БД

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

Построение физической модели сопряжено с решением во многом противоречивых задач:

  1. задачи минимизации места хранения данных,
  2. задачи достижения целостности, безопасности и максимальной производительности.

Вторая задача вступает в конфликт с первой, поскольку, например:

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

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

Для завершения создания физической модели проводят оценку её эксплуатационных характеристик (скорость поиска, эффективность выполнения запросов и расхода ресурсов, правильность операций). Иногда этот этап, как и этапы реализации базы данных, тестирования и оптимизации, а также сопровождения и эксплуатации, выносят за пределы непосредственного проектирования БД.


Потенциальные ключи и уникальные идентификаторы

Потенциальными ключами (candidate keys) являются атрибуты, которые способны уникальным образом идентифицировать строку в таблице, и в каждой таблице таких ключей может быть несколько. Например, достаточно часто в таблице сотрудников присутствует как генерируемый уникальный порядковый номер, так и еще какой-то идентификатор, вроде номера сотрудника (или номера его карточки социального страхования). (Разумеется, любая целая строка сама тоже может служить потенциальным ключом, поскольку в реляционной модели по определению не может существовать никаких дублированных кортежей. Однако целая строка редко применяется в качестве ключа, потому что сам смысл ключа состоит в обеспечении легкого доступа к строке.)

Потенциальный ключ, который в конечном итоге выбирается для уникальной идентификации каждой строки в таблице, называется первичным ключом (primary key). Для простоты и эффективности всегда лучше выбирать стараться такой ключ, который основан на одном, а не на нескольких атрибутах.

Ключи начинают играть очень важную роль, когда дело доходит до физического построения ER-моделей. Первичный ключ, состоящий из элементов данных или атрибутов сущностей, называется естественным (natural). Практически во всех современных реляционных базах данных, в том числе и базах данных Oracle, в качестве альтернативы естественному первичному ключу также предлагаются простые системные или порядковые номера, генерируемые и обслуживаемые РСУБД (наподобие порядкового номера для идентификации заказов). Такие ключи часто называются суррогатными (surrogate) или искусственными (artificial) первичными ключами.

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

  • Значение первичного ключа должно быть уникальным.
  • Первичный ключ не может быть нулевым (пустым).
  • Первичный ключ не может изменяться (он должен оставаться стабильным на протяжении всей жизни сущности).
  • Первичный ключ должен быть настолько коротким, насколько это возможно.

Вас заинтересует / Intresting for you:

Перенос корпоративных баз данн… 653 просмотров Дэн Fri, 27 Sep 2019, 07:52:18

База данных как объект правово… 429 просмотров Денис Wed, 27 Mar 2019, 03:16:24

Оптимизация структур баз данны… 630 просмотров Ирина Светлова Sun, 24 Mar 2019, 06:25:41

База данных и СУБД: основные п… 6814 просмотров Дэйзи ак-Макарова Fri, 24 Nov 2017, 05:30:03

Author: Дэйзи ак-Макарова

Другие статьи автора:

Логическое проектирование БД

Логическая структура БД должна соответствовать логической модели предметной области и учитывать связь модели данных с поддерживаемой СУБД

Поэтому этап начинается с выбора модели данных, где важно учесть её простоту и наглядность

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

Здесь тоже находит отражение природа проектирования, которая допускает возможность (или необходимость) вернуться к концептуальной модели для её изменения в случае, если отражённые там взаимосвязи между объектами (или атрибуты объектов) не удастся реализовать средствами выбранной СУБД.

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

Схемы базы данных формируются с помощью одного из двух разнонаправленных подходов:

  • либо с помощью восходящего подхода, когда работа идёт с нижних уровней определения атрибутов, сгруппированных в отношения, представляющие объекты, на основе существующих между атрибутами связей;
  • либо с помощью обратного, нисходящего, подхода, применяемого при значительном (до сотен и тысяч) увеличении числа атрибутов.

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


С этим читают