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

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

Основные задачи:

• · Обеспечение хранения в БД всей необходимой информации.
• · Обеспечение возможности получения данных по всем необходимым запросам.
• · Сокращение избыточности и дублирования данных.
• · Обеспечение целостности базы данных.

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

• · Концептуальное (инфологическое) проектирование
• · Логическое (даталогическое) проектирование
• · Физическое проектирование

Центральным понятием в области баз данных является понятие модели.

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

Входные и выходные данные задач.

Входными данными задач являются: сведения о препаратах, сведения о заболеваниях, информация о фирмах, цены препаратов, показания по применению и сведения о заказах.

Информация о препарате:

• Ш № Препарата (уникальный)
• Ш Регистрационный номер
• Ш Название препарата
• Ш Международное непатентовое название препарата
• Ш Тип препарата
• Ш Форма выпуска
• Ш Состав и лекарственная форма
• Ш Фармокотерапевтическая группа
• Ш Условия отпуска
• Ш Срок хранения
• Ш Производитель
• Ш Изображение

Информация о заболеваниях:

• Ш Шифр заболевания
• Ш Тип заболевания
• Ш Тип препарата

Показания к применению:

• Ш Название препарата
• Ш Шифр заболевания
• Ш Побочные действия
• Ш Противопоказания
• Ш Способ применения и дозы

Прайс цен:

• Ш №Записи
• Ш №Препарата
• Ш Название препарата
• Ш Шифр фирмы
• Ш Розничная цена
• Ш Количество на складе, штук

Фирмы-поставщики:

• Ш Шифр фирмы
• Ш Название фирмы
• Ш Адрес
• Ш Телефон
• Ш Идентификационный номер

Содержание заказа:

• Ш Регистрационный номер
• Ш №Заказа
• Ш Оптовая цена (за 1 шт)

Заказ по фирме:

• Ш №Заказа
• Ш Шифр фирмы
• Ш Дата заказа
• Ш Количество, штук
• Ш Оптовая цена (за 1 шт)
• Ш К оплате за заказ

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

На этапе инфологического проектирования базы данных строится инфологическая модель предметной области, которая должна отображать смысл взаимосвязи объектов предметной области. ИМД строится не для отдельного объекта, а отображает классы объектов и связи между ними. Диаграмма, отражающая связи объектов предметной области, называется диаграммой ER-типа (так как Entity — сущность, Relationship — связь).

Выделим основные сущности:

• · сущность «Препараты»;
• · сущность «Фирмы»;
• · сущность «Прайс цен»;
• · сущность «Показания к применению»;
• · сущность «Заболевания»
• · сущность «Заказ по фирме»
• · сущность «Содержание заказа»

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

Сущность «Препараты» содержит информацию обо всех препаратах, имеющихся в аптеке. Отдельный препарат этой сущности может поставляться различными фирмами и иметь различные цены в различных фирмах, поэтому водиться сущность «Прайс цен». Каждый препарат сущности «Прайс цен» содержит информацию поставляющей фирме и о цене конкретного препарата. Между сущностью «Препараты» и сущностью «Прайс цен» существует связь типа «1:М», обязательная с обеих сторон (если есть информация о препарате, то есть хотя бы одна фирма, поставляющая данный препарат цена препарата, если есть цена препарата и поставляющая его фирма, то должна быть информация о препарате). Сущность «Фирмы» содержит информацию о фирмах поставляющих препараты. Отдельная фирма этой сущности содержит информацию об одной цене отдельного препарата. Существует связь между сущностью «Фирмы» и сущностью «Прайс цен» типа «1:М», не обязательная с обеих сторон (ни одна фирма может не поставлять ни одного препарата).

Сущность «Препараты» содержит информацию обо всех препаратах, имеющихся в аптеке. Отдельный препарат этой сущности иметь различные показания к применению, поэтому водиться сущность «Показания к применению». Каждое показание к применению сущности «Показание к применению» содержит информацию применению отдельного препарата. Между сущностью «Препараты» и сущностью «Показания к применению» существует связь типа «1:М», обязательная с обеих сторон (если есть информация о препарате, то обязательно должно быть показание к применению, если есть показание к применению, то обязательно должна быть информация о препарате). Сущность «Заболевания» содержит информацию о показаниях к применению, ведь при разных заболеваниях показания к применению могут быть различными. Отдельное заболевание сущности «Заболевания» содержит информацию об одном показании к применению одного препарата. Существует связь между сущностью «Заболевания» и сущностью «Показания к применению» типа «1:М», обязательная с обеих сторон (если есть показание к применению, то должно быть и заболевание, для лечения которого оно предназначено). «Заказ по фирме» относиться к «Фирмы» как «1:М», то есть каждому шифру фирмы соответствует одна фирма. «Содержание заказа «относится к таблице «Заказ по фирме» также «1:М», то есть в одном заказе содержится лишь товар, заказанный у одной фирмы, к таблице «Препараты» также отношение «1:М», то есть определенному номеру препарата соответствует один препарат.

Определим ключи — уникальные идентификаторы каждой сущности: для сущности «Препараты» — это номер препарата (№Препарата), для сущности «Прайс цен» — номер препарата, шифр фирмы, для сущности «Фирмы» — шифр фирмы, для сущности «Показания к применению» название препарата и шифр заболевания, для сущности «Заболевания» — шифр заболевания, в «Заказ по фирме» — номер заказа (№Заказа), в «Содержимое заказа» — регистрационный номер, номер заказа (№Заказа).

Даталогическое проектирование базы данных.

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

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

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

Ограничения или свойства таблиц:

• 1. Каждая таблица представляет собой реальный объект — сущность.
• 2. Элементы таблиц должны быть неделимыми.
• 3. Столбцы — поименованы.
• 4. Элементы столбца должны быть однородными. В таблице не должно быть двух одинаковых строк.
• 5. Каждая таблица должна иметь первичный ключ для идентификации каждой строки таблицы.

В результате получили следующие отношения:

• Ш Препараты
• Ш Прайс цен
• Ш Фирмы
• Ш Показания к применению
• Ш Заболевания
• Ш Заказ по фирме
• Ш Содержание заказа

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

Выбор СУБД Перед непосредственной реализацией, необходимо выбрать СУБД.

Система управления базами данных представляет собой набор различных языковых средств и приложений, необходимых для реализации. В данном проекте выполним физическое проектирование в среде средства СУБД Microsoft Access.

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

Основные компоненты MS Access:

• · построитель таблиц;
• · построитель экранных форм;
• · построитель SQL-запросов (язык SQL в MS Access не соответствует стандарту ANSI);
• · построитель отчётов, выводимых на печать.

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

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

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

Выполним физическое проектирование в среде СУБД Microsoft Access 2010.

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

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

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

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