Проектирование баз данных

Инфологическое проектирование

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

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

Инфологическую модель можно создавать с помощью нескольких методов и подходов:

1. Функциональный подход отталкивается от поставленных задач. Функциональным он называется, потому что применяется, если известны функции и задачи лиц, которые с помощью проектируемой базы данных будут обслуживать свои информационные потребности.
2. Предметный подход во главу угла ставит сведения об информации, которая будет содержаться в базе данных, при том, что структура запросов может не быть определена. В этом случае в исследованиях предметной области ориентируются на её максимально адекватное отображение в базе данных в контексте полного спектра предполагаемых информационных запросов.
3. Комплексный подход по методу «сущность-связь» объединяет достоинства двух предыдущих. Метод сводится к разделению всей предметной области на локальные части, которые моделируются по отдельности, а затем вновь объединяются в цельную область.

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

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

Зависимость сущностей отражается в разделении их на сильные (базовые, родительские) и слабые (дочерние). Сильная сущность (например, читатель в библиотеке) может существовать в БД сама по себе, а слабая сущность (например, абонемент этого читателя) «привязывается» к сильной и отдельно не существует.

Для каждой отдельной сущности выбираются атрибуты (набор свойств), которые в зависимости от критерия могут быть:

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

После этого производится спецификация атрибута, спецификация связей в локальном представлении (с разделением на факультативные и обязательные) и объединение локальных представлений.При числе локальных областей до 4-5 их можно объединить за один шаг. В случае увеличения числа, бинарное объединение областей происходит в несколько этапов.

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

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

Терминология
уровней описания данных и сути
проектирования БД приведена в п. 1.1.3.

Основные цели
проектирования баз данных (ПБД) следующие:

• обеспечение
  хранения в БД всех необходимых данных;

• обеспечение
  получения данных по всем необходимым
  запросам;

• сокращение
  избыточности и дублирования данных;

• обеспечение
  целостности данных: исключение потери
  данных, противоречий в содержании БД,
  нарушений смысла данных;

• сокращение
  времени доступа к данным и получения
  данных по запросам.

В процессе
проектирования баз данных выделяют три
основных этапа.

Концептуальное
(инфологическое) проектирование
– анализ предметной области и ее
описание. Этот этап осуществляется без
ориентации на какие-либо конкретные
программные или технические средства.
Результатом данного этапа является
формализованная модель предметной
области, построенная с использованием
специальных языковых средств (обычно
– графических). Инфологическая модель,
как правило, включает следующие основные
элементы:

• описание объектов
  предметной области;

• описание атрибутов
  (свойств) объектов;

• описание связей
  между объектами.

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

Для
описания объектов предметной области,
их атрибутов и связей между ними обычно
применяются стандартизированные системы
графических обозначений. Чаще всего
применяются ER-модели
(ER-диаграммы),
подробно рассматриваемые в разделе 2,
и семантические объектные модели
(COM-модели),
рассматриваемые в .

Кроме того,
инфологическая модель может включать:

• описание основных
  запросов к проектируемой БД;

• описание
  документооборота, т.е. документов,
  используемых в качестве источников
  данных для БД или составляемых на основе
  БД;

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

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

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

• описание таблиц;

• описание связей
  между таблицами;

• описание атрибутов.

Физическое
проектирование
– описание физической структуры БД,
т.е. ее размещения на запоминающем
устройстве. Такое описание называется
физической моделью. Физическая модель
включает:

• тип носителя;

• способы
  организации данных;

• способы управления
  свободной памятью;

• способы сжатия
  данных и т.д.

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

Примечание — При
использовании систем автоматизированного
проектирования БД этап инфологического
проектирования обычно называют логическим
проектированием, а этапы даталогического
и физического проектирования – физическим
проектированием.

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

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

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

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

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

Замечание 3

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В мир плавных форм от точных прямоугольников

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

Мощь и объективность реляционных отношений — бесспорна, но разве динамика колонок и строк наносит ущерб их репутации? Таблица — это просто данные, которые могут иметь шапку (список колонок) или не иметь строк. Пусть таблица — это просто совокупность данных, не обязательно именованная.

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

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

Предметом работы станет не описание структуры базы данных, а динамика движения информации. Этапы работ распределятся на три центра тяжести:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечание 1

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

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

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

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

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

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

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

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

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

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

Область применения, возможное решение и препятствия

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

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

Парсинг — обширный спектр приложений для систем управления базами данных. Прежде всего — это сканирование информации из интернета

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

Анализ ключевых слов также сопряжен с необходимостью сформировать оптимальное решение, но проектирование баз данных на Access может оказаться перспективнее, чем на MS SQL Server или Oracle.

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

Есть два момента, которые присущи любой базе данных:

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

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

Варианты создания баз данных в Microsoft Access

Пустую базу данных можно создать в проводнике Windows, щелкнув правой кнопкой на пустом пространстве и выбрав «Создать… Базу данных Microsoft Access». Появится пустой файл (ему сразу же можно присвоить подходящее имя), который следует открыть двойным щелчком. Однако в современных версиях программы предусмотрены более эффективные способы выполнения этого действия.

Работа с шаблонами

Можно создать новую БД:

• из стандартного шаблона: несколько готовых шаблонов поставляются вместе с программой;
• из шаблона с сайта Office.com: там имеется обширная коллекция заготовок для баз данных различного назначения; их можно загружать по сети с помощью меню (вкладка «Создать»).

Рисунок 1. Варианты создания новой базы данных в MS Access. Автор24 — интернет-биржа студенческих работ

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

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

Замечание 2

С сайта Office.com можно загружать не только целые шаблоны, но и так называемые «части приложения» — связанные между собой компоненты, например, таблица и построенная на ее основе форма.

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

Создание пустой базы данных

Для создания пустой БД следует на вкладке «Файл» выбрать пункт «Создать» и вариант «Пустая база данных», затем указать имя файла. Access создаст БД с незаполненной таблицей «Таблица1». Она сразу же будет открыта в режиме таблицы. Для добавления данных нужно просто вводить их, отложив оптимизацию структуры колонок. Процесс ввода данных похож на работу с листом Excel.

Замечание 3

Файл Blank.accdb в папке :\Program Files\Microsoft Office\Templates\1049\Access. используется как шаблон для всех новых локальных пустых баз данных. Все новые базы данных наследуют содержимое этого файла. Это отличный способ распространения содержимого по умолчанию.