ВУЗ: Томский государственный университет систем управления и радиоэлектроники
Категория: Учебное пособие
Дисциплина: Базы данных
Добавлен: 28.11.2018
Просмотров: 7747
Скачиваний: 53
76
Рис. 4.2 – Этапы проектирования БД
Подробнее этот этап будет рассмотрен в п. 4.3.
Выбор и приобретение СУБД необходимо будет осуществить между вто-
рым и третьим этапом проектирования. Стоит отметить, что инфологическое
проектирование осуществляется без привязки к конкретной СУБД и в дальней-
шем может быть реализовано в любой из выбранных СУБД. К факторам, кото-
рые влияют на выбор СУБД, стоит отнести следующие: количество пользовате-
лей будущей системы и частота обращений к БД, стоимость СУБД, прикладные
программные средства, которые в дальнейшем будут взаимодействовать с БД,
объем хранимых данных и т. д.
Логическое проектирование – процесс разработки корректной схемы базы
данных в терминах выбранной СУБД. В литературе, помимо термина «логиче-
ское проектирование», также часто используется термин «даталогическое про-
ектирование», однако в рамках данного пособия будет использоваться именно
первый вариант.
Разработка схемы или структуры БД включает в себя создание всех ин-
формационных объектов (таблиц) и связей между ними, определение их имен,
типов данных, длин полей и т. д.
Корректность разработанной БД проверяется на основе анализа функцио-
нальных зависимостей между атрибутами таблиц и связана с теорией нормали-
зации, рассматриваемой в п. 4.2.
Физическое проектирование связано с выбором эффективного размеще-
ния БД на внешних носителях с целью обеспечения максимально эффективного
функционирования информационной системы [8].
Системный анализ предметной области
Инфологическое проектирование
Выбор СУБД
Логическое проектирование
Физическое проектирование
77
3. Реализация информационной системы.
Данный этап завершает реализацию всех требований к информационной
системе, описанных заказчиком, и заключается в решении ряда задач, а именно:
• разработка программного обеспечения;
• тестирование ИС;
• создание рабочей документации, инструкций пользователей по уста-
новке, настройке и эксплуатации.
Основной частью этапа является разработка программного обеспечения
информационной системы, которое будет взаимодействовать с базой данных и
обеспечивать пользовательский интерфейс. Кроме того, неотъемлемой частью
завершения процесса разработки является обязательное тестирование всего
программного комплекса на наличие неисправностей и ошибок. Конечно же, в
любой системе, уже работающей на предприятии, неизбежно возникают сбои и
ошибки при функционировании, т. к. полностью избежать наличия неисправно-
стей в системе невозможно. Тем не менее, задачей разработчиков является ми-
нимизация ошибок в функционировании системы и повышение её надежности
путём проведения целого ряда тестов для выявления максимально возможного
числа ошибок.
По завершению этапа заказчик получает готовую к введению в эксплуа-
тацию информационную систему, в обязательном порядке снабженную рабочей
документацией по установке, настройке и эксплуатации программного ком-
плекса.
4. Внедрение и эксплуатация ИС.
Завершают жизненный цикл этапы внедрения и эксплуатации информа-
ционной системы.
Этап внедрения или ввода системы в эксплуатацию включает в себя про-
цессы установки и настройки программного обеспечения с использованием
имеющегося в организации оборудования и системного программного обеспе-
чения. Зачастую с этим шагом связаны процессы предварительной подготовки
рабочих мест пользователей и технических средств. Ещё одним важным меро-
приятием является обучение персонала взаимодействию с пользовательским
интерфейсом информационной системы. Завершается этап внедрения приемоч-
ными испытаниями системы, когда моделируется реальное взаимодействие
пользователей с новой системой и та уже окончательно переходит в работоспо-
собное состояние – этап эксплуатации.
78
Этап эксплуатации так же, как и остальные, состоит из набора процес-
сов, связанных с ним. Основным из них является непосредственно сама эксплу-
атация системы, т. е. её использование для учёта и анализа имеющейся инфор-
мации всеми пользователями.
В ходе эксплуатации системы неизбежно будут выявляться различные
ошибки и сбои, которые могут быть связаны как с функционированием самой
системы, так и с работой оборудования и имеющегося программного обеспече-
ния, а также при их непосредственном взаимодействии. Вследствие этого на
этапе эксплуатации важны процессы сопровождения системы или технической
поддержки, которые позволят вовремя устранять возникшие проблемы и мини-
мизировать время неработоспособного состояния системы.
Ещё одним важным процессом заключительного этапа является подго-
товка к совершенствованию и модернизации системы. Это связано с постепен-
ным устареванием всего имеющегося оборудования в ходе его эксплуатации, а
также появлением новых более совершенных технологий, программных и тех-
нических средств. В современном мире уже по прошествии 5–7 лет всё имею-
щееся программное и аппаратное обеспечение на предприятии может оказаться
устаревшим, и вопрос модернизации может стать решающим для сохранения
эффективности функционирования любой организации.
Этап эксплуатации системы завершается после полного прекращения ис-
пользования системы и выполнения всех процессов, связанных с технической
поддержкой и модернизацией.
4.2 Нормализация БД
При проектировании баз данных разработчик сталкивается с целым рядом
ситуаций, в которых от выбора наиболее оптимального решения будет зависеть
эффективность дальнейшего функционирования информационной системы.
В некоторых ситуациях в зависимости от масштабов проекта могут быть вы-
браны различные варианты проектирования БД, и некоторые из перечисленных
этапов жизненного цикла информационных систем не обязательно могут быть
реализованы в полной мере.
Так, например, одним из классических методов проектирования баз дан-
ных является метод нормальных форм, или проектирование баз данных с ис-
пользованием методов теории нормализации. Применение нормализации для
поиска максимально эффективной структуры базы данных является одним из
обязательных этапов при использовании любого подхода в проектировании
79
информационных систем. Однако использование только лишь методов норма-
лизации при проектировании баз данных может значительно осложнить эту за-
дачу, особенно для проектов с большим количеством отношений и связей. Та-
ким образом, нормализацию БД лучше всего применять на этапе логического
проектирования, когда уже имеющуюся структуру таблиц необходимо скоррек-
тировать для исключения ситуаций дублирования данных и возникновения раз-
личного вида аномалий.
Использование только метода нормализации для проектирования БД
лучше всего подойдет для проектов с малым количеством объектов и связей.
В этом случае вся информация объединяется в одно большое отношение, кото-
рое в дальнейшем путем декомпозиции разбивается на несколько взаимосвя-
занных.
4.2.1 Дублирование данных
В любой таблице БД может возникнуть ситуация дублирования данных.
Как уже отмечалось, ситуации дублирования данных разработчику необходимо
отслеживать и по возможности устранять. Однако не все ситуации дублирова-
ния отрицательно влияют на корректность БД. А потому важно отличать про-
стое дублирование и аномальное, или избыточное, дублирование данных, т. е.
дублирование, которое приводит к избыточности и аномалиям.
В качестве примеров рассмотрим две таблицы, содержащие сведения о
заказах, сделанных клиентами у компании. Как видно из таблицы 4.1, один и
тот же клиент сделал несколько заказов в разные дни, а потому значение его
атрибута «ФИО» дублируется несколько раз. Или, например, в один и тот же
день было сделано несколько заказов, а потому для всех записей об этом про-
дублировано значение атрибута «Дата заказа». Данный пример иллюстрирует
ситуацию простого дублирования, когда появление одинаковых данных неиз-
бежно и не приводит к аномальным ситуациям.
Таблица 4.1 – Заказы (простое дублирование)
Номер (ПК)
ФИО Клиента Дата заказа Сумма заказа, руб.
568
Иванов С. П.
14.05.2017
22700
569
Петров И. С.
14.05.2017
42000
570
Иванов С. П.
16.05.2017
35200
571
Иванов С. П.
19.05.2017
25000
80
Во втором случае в аналогичной таблице добавим дополнительный атри-
бут, который будет хранить сведения о телефоне клиента. Данные из табли-
цы 4.2 наглядно характеризуют ситуацию аномального дублирования, которая
и приводит к ситуациям неэффективной организации памяти, а также к анома-
лиям.
Таблица 4.2 – Заказы (аномальное дублирование)
Номер
(ПК)
ФИО
Клиента
Телефон
клиента
Дата
заказа
Сумма
заказа, руб.
568
Иванов С. П.
445566
14.05.2017
22700
569
Петров И. С.
778899
14.05.2017
42000
570
Иванов С. П.
445566
16.05.2017
35200
571
Иванов С. П.
445566
19.05.2017
25000
Очевидно, что очередное появление номера телефона клиента, который
регулярно делает заказы, ведет к тому, что это значение постоянно дублирует-
ся, хотя никакой необходимости в каждом повторении самого номера нет.
В качестве одного из возможных решений неопытный разработчик может
предложить вариант однократного занесения номера телефона для каждого
клиента, а в случае дальнейшего появления заказов от того же клиента значение
атрибута «Телефон клиента» можно просто оставлять пустым, как это показано
в таблице 4.3.
Таблица 4.3 – Заказы (аномальное дублирование с пустыми значениями)
Номер
(ПК)
ФИО
Клиента
Телефон
клиента
Дата
заказа
Сумма
заказа, руб.
568
Иванов С. П.
445566
14.05.2017
22700
569
Петров И. С.
778899
14.05.2017
42000
570
Иванов С. П.
–
16.05.2017
35200
571
Иванов С. П.
–
19.05.2017
25000
Однако такой вариант решения проблемы не только не устраняет ситуа-
ции избыточности, но и приводит к другим сложностям. Во-первых, очевидно,
что даже для пустых значений в любой записи в базе данных отводится опреде-
ленное количество памяти, а потому незаполнение данных полей не приведет к