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

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

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

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

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

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

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

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

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

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

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

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

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

Запросы:

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

Отчёты:

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

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

Реляционные базы данных и язык SQL

Фундаментальные знания и жесткие конструкции

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

Алгоритм не может быть фиксированным. Все должно быть определено в динамике. Заслуги квалифицированных разработчиков несомненны, но лежат они вовсе не в изящных формах решений от Oracle, MySQL или ограниченного в возможностях Access. Иная таблица Excel может обеспечить динамичный контент и не требовать участия программиста более менее приличное время после завершения работ.

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

Добавить несколько фото в сторис инстаграм: пошаговые инструкции

Есть несколько методов вставки двух и более фотографий в Stories Instagram. Некоторые из них применимы как для айфонов, так и для смартфонов на базе Android. А некоторые будут работать только на одной из этих операционных систем.

Лайфхак для iPhone

На смартфоне с операционной системой iOS добавлять несколько фото в сторис очень просто:

1. Откройте сторис и добавьте первый кадр.
2. Сверните приложение инстаграм (но не закрывайте его) и войдите в галерею.
3. Найдите второе фото, которое хотите прикрепить.
4. Найдите значок отправки файла (стрелочка, которая указывает вверх). Нажмите на него и выберите «Скопировать фото».
5. Вернитесь обратно в инстаграм. Изображение может появиться сразу. Если этого не произошло, тогда перейдите в режим ввода текста. Для этого нужно нажать один раз на экране или на значок «Аа». Зажмите палец и выберите «Вставить».
6. Теперь можете перемещать изображение, уменьшать, увеличивать, поворачивать и пр.

Добавление нескольких фото на Android

Чтобы добавлять несколько изображений внутри одной истории, нужно установить приложение «SwiftKey». Бесплатная версия доступна в Play Market. Это клавиатура, которая делает ввод тексты быстрее, подстраивается под вас и имеет дополнительные расширенные функции. Одна из них и понадобится для вставки нескольких фото в иснтаграмные истории.

Итак, вы уже скачали «SwiftKey». Теперь:

1. Перейдите в режим создания сторис и добавьте первую фотографию.
2. Нажмите на значок «Аа» или один раз на экране, чтобы перейти в режим ввода текста.
3. Когда откроется клавиатура, найдите иконку в виде канцелярского гвоздика. У некоторых эта функция может прятаться за иконкой GIF. Эти функции будут у вас в самом верху клавиатуры SwiftKey.
4. Нажав на гвоздик, перейдите в раздел «Коллекции». Вы увидите снимки, которые хранятся у вас в галерее.
5. Выберите нужное изображение, и оно добавится в сторис.

Коллаж

В Stories Instagram существует дополнение, которое называется «Коллаж» или «Layout». Найти его можно в нижней строке функций. Там же, где расположены «Бумеранг», «Суперзум», «Прямой эфир» и пр.

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

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, используются повсеместно, востребованы и у них есть, гарантированно обеспеченное работой, будущее.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Замечание 1

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

Создание таблиц и других объектов БД

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

В конструкторе таблиц предусмотрены следующие характеристики полей:

1. размер: для текста это максимально допустимое количество сохраняемых в поле знаков; для числовых полей — варианты «Длинное целое», «Двойное с плавающей точкой» и др.;
2. формат поля — способ отображения данных (текст, число, дата);
3. маска ввода позволяет обеспечить корректность вводимых данных;
4. значение по умолчанию будет отображаться в поле при добавлении новой строки в таблицу;
5. обязательное поле — свойство, указывающее, обязательно ли вводить значение; невозможно будет добавить запись, если в обязательное поле не введено значение.

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

Рисунок 2. Схема данных, показывающая связи по ключевым полям между таблицами. Автор24 — интернет-биржа студенческих работ

Импортирование данных из других источников

Можно скопировать и вставить в таблицу Access данные из других офисных таблиц (Word, Excel). Для этого используется буфер обмена. При этом целесообразно проектировать таблицы БД так, чтобы типы данных в них соответствовали вставляемым. Другой эффективный способ — перенос данных их внешних файлов (текстовых, html, внешних источников) с помощью визардов импорта, которые позволяют контролировать процесс переноса: разбивает текст на колонки, пытается определить типы хранящихся в них данных и заголовки полей и т.п.

Рисунок 3. Импорт данных из внешнего файла. Автор24 — интернет-биржа студенческих работ

Создание запросов, форм, отчетов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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