Методичка БД V.3.0 light (docx)

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

Применяя упрощенную версию модели “сущность-связь”, типы объектов на схеме структуры предметной области будем изображать при помощи прямоугольников, а существенные прямые связи типа “один ко многим” – при помощи стрелок.

Частично формализовать процесс структурирования предметной области позволяет матрица отношений типов объектов, представляющая собой таблицу, заголовками строк и столбцов которой являются типы объектов. На пересечении i-ой строки и j-ого столбца в матрице отношений ставится знак “+”, если между i-ым и j-ым типами объектов имеет место тип отношения “один ко многим”.

Для исключения из матрицы отношений косвенных зависимостей для каждой возможной последовательности каждых трех типов объектов A, B и C (а таких последовательностей можно полу-

чить шесть: A-B-C, A-C-B, B-A-C, B-C-A, C-A-B, C-B-A) необходимо выполнить проверку:

1)стоят ли знаки “+” в строке, соответствующей первому в последовательности типу объектов, и столбцах, соответствующих второму и третьему в последовательности типам объектов;

2)стоит ли знак “+” в строке, соответствующей второму в последовательности типу объектов, и столбце, соответст-

вующем третьему в последовательности типу объектов. При получении утвердительных ответов на оба проверочных

вопроса знак “+” на пересечении строки, соответствующей первому типу объектов, и столбца, соответствующего третьему типу объектов, необходимо исключить из матрицы отношений. Отношение “один ко многим” между первым и третьим типами объектов в этом случае будет косвенным.

На рисунке 2.2 проиллюстрировано применение изложенного приема для последовательности типов объектов A-B-C (тип объектов A является в последовательности первым, B – вторым и C – третьим). Отношение “один ко многим” между типами объектов A и С определено как косвенное и исключено из матрицы отношений.

9

Исходный вариант фрагмента матрицы отношений

Далее типы объектов в матрице отношений распределяются по уровням по алгоритму, представленному на рисунке 2.3.

Прежде всего, в матрице отношений находятся “пустые” столбцы (т.е. те столбцы, в которых не проставлено ни одного знака “+”). Эти столбцы соответствуют типам объектов первого уровня. Затем столбцы и строки, соответствующие типам объектов первого уровня, вычеркиваются из матрицы. Среди оставшихся столбцов проводится поиск “пустых” без учета знаков “+” в вычеркнутых строках. Найденные столбцы будут соответствовать типам объектов второго уровня. Строки и столбцы, соответствующие типам объектов второго уровня, вычеркиваются из матрицы и т.д. Алгоритм в части действий 2-4 повторяется до тех пор, пока из матрицы отношений не будут вычеркнуты все строки и столбцы (и соответственно все типы объектов не окажутся распределены по уровням).

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

10

Рисунок 2.3 – Распределение типов объектов в матрице отношений по уровням

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

11

В очень многих случаях помимо связей типа “один ко многим” при структурировании требуется отображать существенные связи типа “многие ко многим”. Для этой цели могут быть использованы фрагменты структур аналогичные представленному на рисунке 2.4. Если типы объектов A и B связаны как “многие ко многим” и эта связь является существенной, ее придется отобразить, связав типы объектов A и B через некоторый тип объектов C.

C

Рисунок 2.4 – Фрагмент структуры предметной области, отображающий существенную связь типа “многие ко многим” между типами объектов A и B

Обратите внимание: при помощи фрагментов структуры аналогичных представленному на рисунке 2.4 отображаются только существенные (а не все подряд) связи типа “многие ко многим”.

Если при структурировании предметной области были выявлены два типа объектов, которые связаны друг с другом как “ один к одному”, их следует объединить и рассматривать в дальнейшем как один тип объектов, обладающий всеми свойствами каждого из исходных типов объектов.

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

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

12

3. ЭТАПЫ ПРОЕКТИРОВАНИЯ И СОЗДАНИЯ БАЗЫ ДАННЫХ

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

Можно выделить следующие основные этапы проектирования

исоздания базы данных:

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

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

2.Структурирование предметной области По описанию предметной области и функций управления,

которые необходимо реализовать, проектируется ее структура: определяются состав типов объектов и существенные отношения между ними.

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

14

3. Проектирование структуры базы данных

3.1.Определение набора таблиц База данных состоит из линейных таблиц. Каждая табли-

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

-каждая таблица должна содержать данные только на одну тему;

-данные не должны дублироваться. Соблюдение указанных принципов позволяет достичь наибольшей эффективности работы базы и избежать избыточности и противоречивости данных в базе. Эти же принципы используются при определении состава полей.

3.2.Создание словаря имен Всем таблицам и полям должны быть присвоены систем-

ные имена. Сис темные имена нужны для работы СУБД (системы управления базами данных). Конечный пользователь базы данных не обязан знать системные имена.

Системные имена назначаются по определенным правилам. Они должны быть краткими, состоять из букв, цифр

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

Кроме СУБД с системными именами работает разработчик приложения и лицо, которое будет осуществлять сопровождение приложения. Поэтому, системные имена, по возможности, должны отражать содержание таблицы или поля.

Для образования имен сначала составляется словарь – набор слов и их сокращений, которые будут использоваться для образования имен. Словарь должен быть по возможности кратким и хорошо продуманным. Не надо жалеть времени для работы над словарем.

Приведем пример словаря, в котором для каждого слова в скобках укажем принятое сокращение: Номер (Ном), Наименование (Наим), Участок (Уч), Вид (Вид) и т. д.

Образуем системные имена: НомУч, НомВид, НаимУч, НаимВид.

Имя образуется из принятых сокращений слов. Каждое слово в имени начинается с большой буквы.

16

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

3.3.Определение состава и типов полей Таблицы состоят из записей, а записи – из полей. Поля

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

Тип поля зависит от ти па реквизита, но типов полей значительно меньше чем типов реквизитов, поэтому несколько типов реквизитов могут отображаться в один и тот же тип поля.

Часто возникает вопрос, в какой тип поля отобразить реквизит – числовой или текстовый. Существует простое правило решения этого вопроса. Если реквизит по смыслу и содержанию не предназначен и не может участвовать в арифметических операциях, то этот реквизит отображается в текстовое поле. Таким образом, табельные номера, различные коды, номера бухгалтерских счетов и т.п. реквизиты отображаются в поля текстового типа.

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

ний основных свойств полей этой таблицы.

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

17

5.Разработка запросов С помощью запросов можно просматривать, анализировать

и изменять данные из одной или нескольких таблиц. Запросы также используются в качестве источника данных для форм и отчетов. Существуют запросы на выборку, запросы на выборку с группировкой, перекрестные запросы, запросы на изменение, добавление, объединение, удаление данных и другие типы запросов, сочетающие свойства уже перечисленных. В Microsoft Access запросы можно создавать при помощи мастера, в режиме конструктора или с использованием структурированного языка запросов – SQL (Structured Query Language). SQL является общепризнан-

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

6.Разработка отчетов Отчеты представляют собой средство для организации вы-

вода данных на печать и позволяют создавать печатные документы с достаточно сложной структурой.

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

7.Тестирование базы данных Разрабатывается контрольный пример. Контрольный при-

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

При выявлении каких-либо ошибок на этапе тестирования базы данных их следует устранить, вернувшись к одному из

предшествующих этапов.

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

18