Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Методические указания по практикуму ПАС 2012.doc
Скачиваний:
3
Добавлен:
11.11.2019
Размер:
110.59 Кб
Скачать

Московский технический университет связи и информатики

Факультет ИT

Кафедра АИТСС

_______________________________________________________

Дисциплина

«Проектирование автоматизированных систем»

9 семестр

Специальность 22030101

Методические указания

ПО ПРАКТИКУМУ

2010

Методические указания по практикуму

1. Общие сведения о реляционной модели данных

Использование СУБД MS Access в качестве инструмента проектирования АРМ означает, что в создаваемой базе данных будет использована реляционная модель данных. Ниже приведены некоторые сведения о реляционных базах данных.

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

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

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

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

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

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

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

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

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

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

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

В примере, показанном на рис. 1, таблица «Деталь» содержит сведения о деталях, хранящихся на складе, а каждая ее строка — набор значений атрибутов конкретной детали. Столбец «Материал» представляет собой множество значений «Сталь», «Алюминий», «Пластмасса» и т.д. В столбце «Количество» содержатся целые положительные числа. Значения в столбце «Вес» — вещественные числа, равные весу детали в килограммах.

Рис. 1.

Значения в столбце «Материал» выбираются из множества имен всех возможных материалов — пластмасс, древесины, металлов и т.д., пригодных для изготовления деталей. В столбце «Материал» принципиально недопустимо появление значения, которого нет в соответствующем домене, например, «125», «Февраль» или «Песок».

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

Так как строки в таблице не упорядочены, невозможно выбрать строку по ее позиции — среди них не существует «первой», «второй», «последней». Однако любая таблица имеет один или несколько атрибутов, значения в которых однозначно идентифицируют каждую ее строку. Такой атрибут (или комбинация атрибутов) называется первичным ключом (primary key). В нашем примере каждая деталь на складе имеет единственный номер, по которому из таблицы «Деталь» может быть извлечена необходимая информация. В таблице «Деталь» первичный ключ — это столбец «Номер детали». В нем значения не могут дублироваться — в таблице «Деталь» не должно быть строк, имеющих одно и то же значение в столбце «Номер детали». Если таблица удовлетворяет этому требованию, она называется отношением.

Можно представить себе базу данных, отображающую единственную сущность и имеющую единственную таблицу. Однако для работы с такими простыми информационными объектами вполне возможно использовать не столь мощные и сложные в освоении программные средства, как СУБД MS Access, например, текстовый процессор MS Word или табличный процессор MS Excel.

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

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

Связь таблиц является важнейшим элементом реляционной модели данных. Она поддерживается внешними ключами (foreign key).

Рассмотрим пример, в котором база данных хранит информацию о рядовых сотрудниках (таблица «Сотрудник») и руководителях (таблица «Руководитель») в некоторой организации (рис.2). Первичный ключ таблицы «Руководитель» — атрибут «Номер» (например, табельный номер). Атрибут «Фамилия» не может играть роль первичного ключа, так как в одной организации могут работать два руководителя с одинаковыми фамилиями.

Любой сотрудник подчинен единственному руководителю, что должно быть отражено в базе данных. Таблица «Сотрудник» содержит атрибут «Номер руководителя», и значения в этом столбце выбираются из столбца «Номер» таблицы «Руководитель». Атрибут «Номер Руководителя» является внешним ключом в таблице «Сотрудник».

Таблицы невозможно хранить и обрабатывать, если в базе данных отсутствуют «данные о данных», например, описатели таблиц, столбцов и т.д. Их называют обычно метаданными. Метаданные также представлены в табличной форме и хранятся в словаре данных (data dictionary).

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

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

Рис. 2.

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