Проектирование – это разработка принципов построения и эффективного функционирования систем, процессов и др.
Проектирование любого объекта осуществляется с:
а) определения его функционального назначения (зачем нужен, что и как делает проектируемый объект),
б) выявления логических связей (как осуществляет своё функциональное назначение проектируемый объект, какая информация и в какой последовательности обрабатывается),
в) выбора материальных средств реализации проектируемого объекта – функционально-технологический и технический аспект (носители, средства обработки данных и др.),
г) пространственного (территориального) размещения материальных средств реализации на выделенных или возможных для использования площадях,
д) формирования организационно-управленческой структуры проектируемого объекта (состав подразделений, полномочия и функциональные обязанности работников).
Современный подход к созданию информационных систем заключается не в создании системы на базе какого-либо интегрированного продукта, а в тщательном её проектировании и лишь потом реализации с помощью адекватных программных средств.
Под проектированием любого объекта понимается процесс построения его образа, используемого затем для определённой (заданной) цели.
Проектирование информационных систем, включающих в себя базы данных, осуществляется на физическом и логическом уровнях.
Решение проблем проектирования на физическом уровне во многом зависит от используемой СУБД, зачастую автоматизировано и скрыто от пользователя. В ряде случаев пользователю предоставляется возможность настройки отдельных параметров системы, которая не составляет большой проблемы.
Логическое проектирование заключается в определении числа и структуры таблиц, формировании запросов к БД, определении типов отчетных документов, разработке алгоритмов обработки информации, создании форм для ввода и редактирования данных в базе и решении ряда других задач.
Решение задач логического проектирования БД в основном определяется спецификой задач предметной области. Наиболее важной является проблема структуризации данных.
При проектировании структур данных для автоматизированных систем можно выделить три основных подхода:
1. Сбор информации об объектах решаемой задачи в рамках одной таблицы (одного отношения) и последующая декомпозиция ее на несколько взаимосвязанных таблиц на основе процедуры нормализации отношений.
2. Формулирование знаний о системе (определение типов исходных данных и их взаимосвязей) и требований к обработке данных. При этом с помощью CASE-систем можно получить готовые схемы БД или даже готовую прикладную информационную систему.
3. Структурирование информации для использования в информационной системе в процессе проведения системного анализа на основе совокупности правил и рекомендаций.
Для успешного проведения проектных работ рекомендуется выявить один или несколько прототипов проектируемого объекта, на их основе разработать некоторое количество возможных вариантов (их количество, как правило, в несколько раз больше числа выявленных прототипов). Например, для определения организационно-управленческой структуры автоматизируемой организации в качестве прототипа можно использовать существующую её структуру.
Затем из полученных вариантов следует отобрать альтернативные разновидности. С учётом местных условий и локальных ограничений сократить оставшиеся варианты, из которых выбрать наилучшие решения.
При проектировании рассматривается как внешняя, так и внутренняя среда объекта. В качестве макро среды организации выступают: пользователи (клиенты, заказчики) и их запросы; поставщики информации (информация об информации), исходящие и входящие информационные потоки, направляемые в организацию; внешние органы управления организацией. Применение унифицированных проектных решений базируется на типовых функциях и характеристиках организации.
В одном подразделении организации объектом может выступать отдельная операция или процесс (цикл), состоящий из нескольких операций.
Если группа подразделений является областью применения технических средств, то возникает потребность организации автоматизированной последовательности выполнения нескольких операций (процессов) конвейерным способом, например, применяемым в промышленности при изготовлении сложных агрегатов. Интеграция нескольких процессов создаёт предпосылки формирования комплексной системы для наиболее полного решения основных задач.
Исходными данными, промежуточными и конечными результатами процесса проектирования являются описания объекта, сделанные на специальном и (или) естественном языке.
Этапы проектирования баз данных
Этап 1. Определение сущностей.
Этап 2. Определение взаимосвязей между сущностями.
Этап 3. Задание первичных и альтернативных ключей, определение атрибутов сущностей.
Этап 4. Приведение модели к требуемому уровню нормальной формы.
Этап 5. Физическое описание модели.
Проектирование реляционных баз данных с использованием нормализации.
Приведение модели к требуемому уровню нормальной формы является основой построения реляционной БД.
В процессе нормализации элементы данных группируются в таблицы, представляющие объекты и их взаимосвязи. Нормализация основана на том, что определенный набор таблиц обладает лучшими свойствами при включении, модификации и удалении данных, чем все остальные наборы таблиц, с помощью которых могут быть представлены те же данные. Введение нормализации отношений при разработке информационной модели обеспечивает минимальный физический объем БД и ее максимальное быстродействие, что отражается на качестве функционирования ИС.
Нормализация информационной модели выполняется в несколько этапов. Данные, представленные в виде двумерной таблицы, являются первой нормальной формой реляционной модели данных.
Первый этап нормализации заключается в образовании двумерной таблицы, содержащей все необходимые атрибуты информационной модели, и в выделении ключевых атрибутов. При этом обычно получается внушительная таблица, содержащая разнородную информацию; наблюдаются аномалии включения, обновления и удаления данных, неимеющих никакого отношения к текущим действиям. Например, при включении в каталог продаж новой модели автомобиля сразу же придётся указать купившего ее клиента.
Ключевое поле – это одно или несколько полей, комбинация значений которых однозначно определяет каждую запись в таблице. Это уникальный идентификатор записей, используемый для поиска записей и объединения таблиц. Ключевое поле в таблице не может содержать пустые и повторяющиеся значения.
Ключевое поле в таблице используется для поиска записей. При ссылке на ключевое поле из другой таблицы оно называется полем внешнего ключа.
В качестве ключевого поля обычно рекомендуется использовать идентификационный или табельный номер. Так как оно является предметным словом и выбирается из текста для его индексирования, то ключевое слово является фрагментом текста, отражающим содержание документа.
Запись данных – это полный набор данных об определенном объекте; это любая строка в таблице данных. Физически в базах данных понятию запись данных соответствует понятие структуры.
Отношение считается заданым во второй нормальной форме, если оно является отношением в первой нормальной форме и каждый атрибут, не являющийся первичным атрибутом в этом отношении, полностью зависит от любого возможного ключа этого отношения.
Приведение отношений ко второй нормальной форме заключается в обеспечении полной функциональной зависимости всех атрибутов от ключа за счёт разбиения таблицы на несколько, в которых все имеющиеся атрибуты будут иметь полную функциональную зависимость от ключа этой таблицы. В процессе приведения модели ко второй нормальной форме в основном исключаются аномалии дублирования данных.
Отношение задано в третьей нормальной форме, если оно задано во второй нормальной форме и каждый атрибут этого отношения, не являющийся первичным, не транзитивно зависит от каждого возможного ключа этого отношения.
Транзитивная зависимость выявляет дублирование данных в одном отношении. Если А, В и С – три атрибута одного отношения и С зависит от В, а В от А, то говорят, что С транзитивно зависит от А.
Например, если все данные о моделях автомобилей и самих поступающих автомобилях хранятся в одном отношении, то для нескольких автомобилей одной модели надо многократно указывать тип кузова и другие технические характеристики. В этом случае технические характеристики зависят от модели автомобиля и, при наличии нескольких автомобилей одной модели, будут дублироваться. Дублирование исчезает, если из одного отношения выделить отношение, в котором будут храниться данные о моделях, и отношение, в котором будут храниться данные об автомобилях.
ПРОЕКТИРОВАНИЕ БД В СРЕДЕ MS ACCESS
Обоснование выбора СУБД
Обоснование выбора СУБД рассмотрим на примере СУБД Access, входящей в состав пакета прикладных программ (ППП) Microsoft Office. При выборе любой программы первоначально рассматриваются её возможности, среда применения, пользователи, их квалификация и т.п.
Широкое распространение имеет система управления базами данных Access. Она предназначена для работы на автономном компьютере или в локальной вычислительной сети под управлением операционной системы Microsoft Windows, поэтому все преимущества Windows (например, вырезать, копировать и вставлять данные из любого приложения Windows) могут использоваться в Access и наоборот.
Access привлекает простотой освоения и возможностью использования непрофессиональным программистом. Он имеет мощные средства подготовки отчетов из БД различных форматов. Поэтому его основное назначение – создание отчетов произвольной формы на основании различных данных и разработка некоммерческих приложений. Она является набором инструментальных средств, предназначенных для создания и эксплуатации информационных систем.
Access - это популярная настольная система управления базами данных. Её успех можно связать с великолепной рекламной кампанией, организованной Microsoft, и включением её в богатое окружение продуктов семейства Microsoft Office, c прекрасной реализацией продукта, рассчитанного как на начинающего, так и квалифицированного пользователя.
СУБД Access является набором инструментальных средств, предназначенных для создания и эксплуатации информационных систем, для управления базами данных.
К удобным для пользователей и разработчиков средствам Access относятся мастера и конструкторы таблиц, форм, запросов и отчётов. Она позволяет автоматизировать часто выполняемые операции (например, расчёт заработной платы, учёт материальных ценностей и т.п.), разрабатывать удобные формы ввода и просмотра данных, составлять сложные отчёты и др.
Таблица в Access является основным структурный объектом внутреннего строения БД. В неё включают записи определённого вида. Каждая запись таблицы содержит всю необходимую информацию об отдельном объекте – элементе БД. По многим причинам вводить все данные в одну таблицу нерационально, поэтому в Access предусмотрен механизм создания связанных между собой разных таблицы с различными видами данных. Таблицу Access можно связать с данными, хранящимися на другом компьютере или на сервере. В Access можно использовать таблицу, созданную в СУБД Paradox или Dbase. Данные Access очень просто комбинировать и с данными из Excel и т.п.
С помощью средств Access можно выполнять следующие операции:
1. Проектировать базовые объекты ИС – двумерные таблицы с разными типами данных, включая поля объектов OLE. Например, прежде чем заполнять данными любую таблицу, надо создать её макет.
2. Устанавливать связями между таблицами с поддержкой целостности данных, каскадным обновлением полей и каскадным удалением записей.
3. Осуществлять ввод, хранение, просмотр, сортировку, модификацию и выборку данных из таблиц с использованием различных средств контроля информации, индексирования таблиц и аппарата алгебры логики (для фильтрации данных).
4. Создавать, модифицировать и использовать производные объекты ИС (формы, запросы и отчёты).
Совокупность связей между элементами, отражающими их взаимодействие называют структурой системы. Состояние системы в любой момент времени характеризуется её структурой.
Для проектирования БД необходимо, в первую очередь, представить себе предметную область (например, телефонная связь), её потребности, и возможности ПО для реализации данной задачи.
При разработке структуры любой таблицы реляционной БД изначально определяют названия полей, из которых она должна состоять, типы полей и их раз-меры. Каждому полю таблицы присваивается уникальное имя. Лучше, когда содержание или функция поля узнаются по нему.
Затем определяют типа данных, содержащихся в каждом поле. Один из типов данных должен быть присвоен каждому полю. В таблице 1 представлены типы данных, используемые в Access и их описание. Тип данных в таблице характеризует вид хранящихся в поле данных.
Таблица 1. Типы данных Access.
| Тип данных | Описание |
| Текстовый
(по умолчанию) | текст или числа, не требующие проведения расчетов, например номера телефонов (до 255 знаков) |
| Числовой | числовые данные различных форматов, используемые для проведения расчетов |
| Дата/время | для хранения информации о дате и времени с 100 по 9999 год включительно |
| Денежный | денежные значения и числовые данные, используемые в математических расчетах, проводящихся с точностью до 15 знаков в целой и до 4 знаков в дробной части |
| Поле MEMO | для хранения комментариев; до 65535 символов |
| Счетчик | специальное числовое поле, в котором Access автоматически присваивает уникальный порядковый номер каждой записи. Значения полей типа счетчика обновлять нельзя |
| Логический | может иметь только одно из двух возможных значений (True/False, Да/Нет) |
| Поле объекта OLE | объект (например, электронная таблица Microsoft Excel, документ Microsoft Word, рисунок, звукозапись или другие данные в двоичном формате), связанный или внедренный в таблицу Access |
| Гиперссылка | строка, состоящая из букв и цифр и представляющая адрес гиперссылки. Адрес гиперссылки может состоять максимум из трех частей: текст, выводимый в поле или в элементе управления; путь к файлу (в формате пути UNC) или к стра-нице (адрес URL). Чтобы вставить адрес гиперссылки в поле или в элемент управления, выполните команду Вставка, Гиперссылка |
| Мастер подстановок | создает поле, в котором предлагается выбор значений из списка или из поля со списком, содержащего набор постоянных значений или значений из другой таблицы. Это в дейст-вительности не тип поля, а способ хранения поля |
Разработка информационно-логической модели реляционной БД начинается с рассмотрения необходимых для её создания информационных объектов. Рассмотрим вариант БД «Деканат». Выделим три объекта, не обладающие избыточностью: Студенты, Дисциплины и Преподаватели.
Рассмотрим связь между объектами "Студенты" и "Дисциплины". Студент изучает несколько дисциплин. Каждая дисциплина изучается множеством студентов – это тоже многозначная связь. Следовательно, связь между объектами "Студенты" и "Дисциплины" – «Многие-ко-многим» (М : N).
Практически любая реляционная БД (в том числе и в Access) создаётся из нескольких таблиц, на основе которых формируются формы и запросы. В таблицах Access форма является объектом, предназначенным для ввода данных. В форме Access можно разместить элементы управления и изображения.
Таблицы между собой связываются посредством общих полей, т.е. полей, одинаковых по форматам и, как правило, по названию, имеющихся в обеих таблицах. Такая организация данных позволяет уменьшить избыточность хранимых данных, упрощает их ввод и организацию запросов и отчётов. Каждая таблица включает в свой состав поле кода, используемого обычно как счётчик (идентификатор) главного её параметра и, как правило, являющегося ключевым полем.
Обычно используются три вида связей между таблицами: «Один-ко-многим», «Многие-ко-многим» и «Один-к-одному».
Наиболее часто используется тип связи между таблицами «Один-ко-многим». В такой связи каждой записи в таблице «А» может соответствовать несколько записей в таблице «В» (поля с этими записями называют внешними ключами), а запись в таблице «В» не может иметь более одной соответствующей ей записи в таблице «А». Подобная связь создаётся, когда только одно из полей таблицы является ключевым или имеет уникальный индекс, т.е. значения в нём не повторяются.
При связи «Многие-ко-многим» одной записи в таблице «А» может соответствовать несколько записей в таблице «В», а одной записи в таблице «В» – несколько записей в таблице «А». Такая схема реализуется только с помощью третьей (связующей) таблицы, ключ которой состоит, по крайней мере, из двух полей, одно из которых является общим с таблицей «А», а другое – общим с таблицей «В». Она фактически представляет две связи типа «один-ко-многим» через третью таблицу.
При связи «Один-к-одному» запись в таблице «А» может иметь только одну связанную запись в таблице «В» и наоборот. Этот тип связи используют редко, так как такие данные могут быть помещены в одну таблицу. Связь с отношением «Один-к-одному» применяют для разделения очень широких таблиц, для отделения части таблицы в целях её защиты, а также для сохранения сведений, относящихся к подмножеству записей в главной таблице. Она создаётся, когда оба связываемых поля являются ключевыми или имеют уникальные индексы.
Множественные связи усложняют управление базой данных, поэтому их использовать нежелательно. Нужно строить реляционную модель, не содержащую связей типа «Многие-ко-многим».
В Access для контроля целостности данных с возможностью каскадного обновления и удаления данных создают вспомогательный объект связи, состоящий из ключевых реквизитов связываемых объектов, который может быть дополнен описательными реквизитами. В данном случае таким новым объектом для связи может быть объект «Оценки».
Его реквизиты: код студента, код дисциплины и собственно оценки. Каждый студент имеет оценки по нескольким дисциплинам Связь между объектами «Студенты» и «Оценки» будет «Один-ко-многим» (1 : М).
Каждую дисциплину сдает множество студентов, поэтому связь между объектами «Дисциплины» и «Оценки» также будет «Один-ко-многим» (1 : М).
Создавая структуры таблиц «Студенты», «Оценки», «Дисциплины» и «Преподаватели», определим в них общие поля, необходимые для обеспечения связности данных. В таблицах «Студенты» и «Оценки» таким полем будет «Код студента», в таблицах «Дисциплины» и «Оценки» – «Код дисциплины», в таблицах «Преподаватели» и «Дисциплины» – «Код дисциплины».
Можно выбрать цифровые коды вместо полей «фамилий» или «названий дисциплин». Это позволит обеспечить меньший объёмом информации в данных полях. Например, число «5» по количеству символов значительно меньше слова «математика».
При формировании набора объектов необходимо приписать и сообщить системе: точное имя, его длину и структуру. Эти действия связаны с определением параметров полей таблиц (имени поля, типа данных и размер поля).
Тип данных в таблице характеризует вид хранящихся в поле данных. В современных СУБД допускаются следующие типы данных: символьные, текстовые, числовые, логические, битовые строки, мемо, счетчик , OLE-объекты, гиперссылки и специализированные данные (время, дата, временной интервал, денежные единицы).
Заполнять сразу таблицы данными не следует. Это лучше делать в режиме формы. Форма в таблицах Access является объектом, предназначенным для ввода данных. В ней также можно разместить элементы управления и изображения.
После создания всех таблиц формируют схему данных, т.е. создают связи между таблицами.
Затем создают формы всех таблиц и заполняют их необходимыми данными. В процессе ввода первых данных в формы проверяется правильность создания их, таблиц и связей между таблицами.
В дальнейшем выполняются рабогты по формированию различных запросов и отчётов.
Сформированный в БД запрос создается снова при каждом выполнении запроса и автоматически обновляется при его запуске.
Простой запрос на выборку из определённых полей таблиц или других запросов можно организовать с помощью мастера запросов. Результат работы простых запросов на выборку практически не отличается от использования фильтров.
Общие изменения в группу записей одной или нескольких таблиц вносят с помощью запроса на обновление записей.