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

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

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

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

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

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

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

Это обстоятельство определяет возникновение следующего этапа – появления обеспеченной средствами конкретной СУБД концептуальной модели. Данный шаг соответствует этапу логического проектирования (создания логической модели).

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

Таким образом, основные этапы проектирования в детализированном виде представлены этапами:

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

Ключевые из них ниже будут рассмотрены подробнее.

2.1. Этапы проектирования бд

Современные
информационные системы характеризуются
огромными объемами хранимых данных,
большой скоростью их обработки и
актуализации, высокой эффективностью
обработки запросов пользователей. В
широком смысле слова база данных – это
совокупность сведений о конкретных
объектах реального мира в какой-то
предметной области.

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

Проектирование
базы данных состоит в построении
комплекса взаимосвязанных данных. На
рисунке 1 условно отображены этапы
процесса проектирования базы данных.

Рис.1 — Этапы процесса
проектирования базы данных

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

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

Концептуальное
проектирование
– сбор, анализ и редактирование требований
к данным. Для этого осуществляются
следующие мероприя­тия:

—
обследование предметной области,
изучение ее информационной структуры;

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

·-
моделирование и интеграция всех
представлений.

Результат
данного этапа – концептуальная модель,
ин­вариантная к структуре Базы данных,
часто представляется в виде модели
«сущ­ность-связь».

Логическое
проектирование– преобразование
требований к данным в структуры данных.
Результат – СУБД-ориентированная
структура Базы данных и спецификации
прикладных программ. На этом этапе часто
мо­делируют Базы данных применительно
к различным СУБД и проводят сравнительный
анализ моделей.

Физическое
проектирование
– определение особенностей хранения
данных, методов доступа и т. д. Физическая
база данных нужна разработчикам
информационной сис­темы для разработки
кода, а проектировщикам – для проверки
их идей. Проектировщики и разработчики
могут работать как с одной и той же
схемой, так и с разными схемами. В процессе
разработки проекта, как правило, создается
несколько версий схемы.

Построение
логической и физиче­ской моделей
данных является основной частью
проектирования Базы данных.

Связи и виды связей

На пятом этапе проектирования необходимо спроектировать связи между таблицами. Связи моделируют отношение между сущностями предметной области.

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

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

Попробуем добавить поле «Код товара» в таблицу «Поставщики» и показать, что поставщик «Ашан» поставляет оба вида молока и сыр.

Замечание 3

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

Второй способ тоже приведет к нарушению 1 н.ф.

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

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

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

2.4. Microsoft Access 2007

2.4.2. Создание базы данных (таблиц и связей между ними) в Access 2007

Рассмотрим этапы создания БД «Деканат» с помощью СУБД Access 2007. Сначала составляем модель «сущность – связь» для базы данных «Деканат». Этапы проектирования модели «сущность – связь» изложены в разделе «Создание БД. Этапы проектирования».

После создания модели запускаем приложение Access 2007. Открывается окно приложение Access 2007 на странице Приступая к работе с Microsoft Access 2007. В разделе Новая пустая база данных щелкаем на пиктограмме Новая база данных. В правой части окна появится информация об имени файла и указана директория для его хранения. По умолчанию имя файла — База данных1.accdb.

Изменить имя файла и путь к директории для хранения файла БД можно в окне «Файл новой базы данных» щелкнув на пиктограмме «Поиск расположения для размещения базы данных». Установив имя файла — Деканат_2007.accdb и требуемое имя директории в окне «Файл новой базы данных», надо щелкнуть на кнопке ОК, окно закроется.

Далее необходимо щелкнуть на кнопке Создать, чтобы создать пустую базу данных. При создании новой пустой базы данных окно приложения Access 2007 открывается на контекстной вкладке «Режим таблицы». В окне отображается новая пустая таблица с именем Таблица 1 в режиме таблица, представленная на Рис. 1.

Рис. 1.

Далее необходимо перейти в режим Конструктор и создать структуру первой таблицы базы данных. Для этого необходимо щелкнуть на пиктограмме Вид и выбрать режим Конструктор.

Рис. 2.

Откроется окно Сохранение, в котором надо указать имя Группы студентов и нажать кнопку ОК.

Рис. 3.

Откроется таблица Группы студентов в режиме Конструктор

Рис. 4.

Создаем структуру таблицы Группы студентов. В первую строку колонки «Имя поля» вводим код группы студентов (КодГруппы) и нажимаем клавишу Enter. Курсор переместится в колонку Тип данных. Access по умолчанию назначает тип данных — Счетчик. Нажимаем клавишу Enter, при этом курсор переместится в колонку Описание, при необходимости вводим описание данных.

Первой строке таблицы (поле КодГруппы) Access по умолчанию назначает поле первичного ключа. Для первичного ключа в свойствах поля устанавливается значение Индексированного поля: Да (Совпадения не допускаются). Далее заполняем вторую строку (второе поле таблицы), Имя поля — Название, Тип данных — текстовый. Третья строка: Имя поля — Курс, Тип данных — числовой и четвертая строка Имя поля — Семестр, Тип данных — числовой. При этом для имени поля «Название» в разделе свойства поля необходимо установить размер поля — 6.

Рис. 5.

Затем создаем структуры остальных трех таблиц в соответствии с характеристиками таблиц-объектов Студенты, Дисциплины, Успеваемость. Обязательно соблюдайте указанную последовательность создания структуры таблиц.

Необходимо отметить, что в структуре таблицы «Студенты» для поля КодГруппы (вторичный ключ) установите значение Индексированного поля: Да (Совпадения допускаются) и тип данных — мастер подстановок. В структуре таблицы «Успеваемость» для поля КодСтуденты (вторичный ключ) и поля КодДисциплины (вторичный ключ) установите значение Индексированного поля: Да (Совпадения допускаются) и тип данных — мастер подстановок.

Структуры остальных таблиц: Студенты, Дисциплины, Успеваемость:

Рис. 6

Рис. 7

Рис. 8

После этого необходимо установить логические связи между всеми таблицами.

Далее >>> 2.4.3. Установка связей между таблицами в СУБД Access 2007

Современная база данных

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

Таблицы Excel — ничем не отличаются от Oracle и MySQL в контексте прямоугольных (реляционных) конструкций: столбцы и строки = одна ячейка на пересечении имени столбца (поля) и индекса выборки (строка). Если не учитывать меру и объем ручного труда, то, благодаря развитым средствам объединения ячеек по вертикали и горизонтали, Excel опережает даже Oracle!

Excel, по его основной идее, никогда «не светит» динамика, функционал Oracle, и перенести что-то с одного листа на другой «по остаткам» он не может. Здесь Oracle перспективнее, но ее соображения по вопросам миграции больших объемов информации и объединению формализованных позиций из различных источников оставляют желать лучшего. Здесь MySQL перспективнее: она не ставит перед собой глобальных задач, но свою работу исполняет отменно.

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

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

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

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

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

Литература

• Дейт К. Дж. Введение в системы баз данных = 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.

Краткие сведения о субд Access

База
данных в Access
представляет собой единый большой
объект, который объединяет такие
составляющие, как таблицы, отчеты,
запросы, формы и т.д. и позволяет хранить
их в одном файле.

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

Каждый объект и
элемент управления имеет свои свойства,
определяя которые можно настраивать
объекта и элементы управления.

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

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

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

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

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

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

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

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

Запросы к базе данных и отчёты

Запросы:

• доступность выбираемого в селекторе препарата в выбираемой в селекторе аптеке на данный момент времени;
• группы препаратов, которых нет в выбираемой в селекторе аптеке на данный момент времени;
• аптеки, в которых есть дефицит любого препарата по введённой дате;
• покупки препаратов, которые есть на витринах аптек по введённой дате с указанием препаратов и аптек;
• клиенты, совершившие покупки в выбранной в селекторе аптеке по введённой дате.

Отчёты:

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

Поделиться с друзьями

Реляционные базы данных и язык 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)
);

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

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

Для изучения предметной области разработчик использует следующие способы:

• Беседы с потенциальными пользователями базы данных.
• Изучение нормативных документов, на основании которых происходят бизнес-процессы. Это могут быть уставы, лицензии, нормативные акты.
• Изучение оперативных документов, которые отражают бизнес-процессы. Это могут быть различные накладные, квитанции, платежные поручения.

На втором этапе проектирования разработчик должен выделить сущности предметной области. Сущностью предметной области называется абстрактное представление группы объектов с одинаковыми свойствами. Например, молоко, сыр, сметана – это конкретные продукты, но все вместе они относятся к сущности «продукция молокозавода» или «товар». Сущности предметной области описываются атрибутами. Атрибуты сущности – это абстрактные характеристики сущности, конкретные значения которых определяют конкретный экземпляр сущности. Например, сущность «продукция молокозавода» может описываться следующими атрибутами: наименование продукции, тип упаковки, вес, жирность. Если задать этим атрибутам конкретные значения, то мы получим описание конкретного продукта, выпускаемого молокозаводом. Например, молоко в тетрапаке весом 0.5л. и жирностью 3.2%.

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

1. Один поставщик может поставлять много товаров.
2. Один товар может поставляться многими поставщиками.

Приведем еще один пример. Рассмотрим сущности «автомобили» и «владельцы автомобилей». Между ними имеется отношение «владения автомобилем». Его описание будет выглядеть так:

1. Один владелец может владеть многими автомобилями.
2. Один автомобиль может принадлежать только одному владельцу.

Подобные описания отношений между сущностями называются ограничениями предметной области.

Замечание 1

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