Модель объект - свойство - отношение. Выявление информационных объектов и связей между ними

1. Основные понятия и термины к теме
“ИНФОРМАЦИОННАЯ МОДЕЛЬ – ОСНОВА ПОСТРОЕНИЯ
СИСТЕМЫ УПРАВЛЕНИЯ БАЗАМИ ДАННЫХ.

Каждой цивилизации приходится иметь дело с обработкой информации. С развитием экономики и ростом численности населения возрастает и объем взаимосвязанных данных, необходимых для решения коммерческих и административных задач.

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

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

Чтобы понять процесс построения информационной системы, необходимо знать ряд терминов, которые применяются при описании и представлении данных.

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

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

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

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

@ Объектом называется элемент информационной системы, информацию о котором мы сохраняем. В реляционной теории баз данных объект называется сущностью.

Объект может быть реальным (например, человек, какой-либо предмет или населенный пункт) и абстрактным (например, событие, счет покупателя или изучаемый студентами курс). Так, в области продажи автомобилей примерами объектов могут служить МОДЕЛЬ АВТОМОБИЛЯ, КЛИЕНТ и СЧЕТ. На товарном складе - это ПОСТАВЩИК, ТОВАР, ОТПРАВЛЕНИЕ и т. д. Каждый объект обладает определенным набором свойств, которые запоминаются в информационной системе. При обработке данных часто приходится иметь дело с совокупностью однородных объектов, например таких, как служащие, и записывать информацию об одних и тех же свойствах для каждого из них.

@ Классом объектов называют совокупность объектов, обладающих одинаковым набором свойств.

Таким образом, для объектов одного класса набор свойств будет одинаков, хотя значения этих свойств дл я каждого объекта, конечно, могут быть разными. Например, класс объектов МОДЕЛЬ свойств дл я каждого объекта, конечно, могут быть разными. Например, класс объектов МОДЕЛЬ АВТОМОБИЛЯ будет иметь одинаковый набор свойств, описывающих характеристики автомобилей, и каждая модель будет иметь различные значения этих характеристик.

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

@ Атрибут - это информационное отображение свойств объекта. Каждый объект характеризуется рядом основных атрибутов.

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

Рис. 1.1. Три области представления данных.

@ Таблица - это некоторая регулярная структура, состоящая из конечного набора однотипных записей. В некоторых источниках таблица называется отношением.

Мы постараемся избегать последнего термина, так как с развитием реляционной теории “отношением” наряду с термином “связь” часто стали называть связи между таблицами. Каждая запись одной таблицы состоит из конечного (и одинакового!) числа полей , причем конкретное поле каждой записи одной таблицы может содержать данные только одного типа.

@ Значения данных представляют собой действительные данные, содержащиеся в каждом элементе данных.

Элемент данных “НАИМЕНОВАНИЕ МОДЕЛИ” может принимать такие значения, как “Voyager"96 3.8 Grand ”, “Continental 4.6” или “Crown Victoria 4.6” . В зависимости от того, как элементы данных описывают объект, их значения могут быть количественными, качественными или описательными. Информацию о некоторой предметной области можно представить с помощью нескольких объектов, каждый из которых описывается несколькими элементами данных. Принимаемые элементами данных значения называются данными .

@ Единичный набор принимаемых элементами данных значений называется экземпляром объекта . Объекты связываются между собой определенным образом.

@ Соответствующая модель объектов с составляющими их элементами данных и взаимосвязями называется концептуальной моделью предметной области. Концептуальная модель дает представление о потоке данных в предметной области.

Некоторые элементы данных обладают важным для построения информационной модели свойством. Если известно значение, которое принимает такой элемент данных объекта, мы можем идентифицировать значения, которые принимают другие элементы данных этого же объекта. Например, зная уникальный номер модели автомобиля - 7, мы можем определить, что это “Voyager" 96” и что рабочий объем двигателя у данной модели “ 3778” .

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

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

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

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

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

Например, для объекта “СЛУЖАЩИЙ”, который имеет атрибуты “ИДЕНТИФИКАТОР СЛУЖАЩЕГО”, “ФАМИЛИЯ”, “ИМЯ” и “ОТЧЕСТВО”, группа атрибутов “ФАМИЛИЯ”, “ИМЯ”, “ОТЧЕСТВО” может являться альтернативным ключом по отношению к атрибуту “ИДЕНТИФИКАТОР СЛУЖАЩЕГО” (в предположении, что на предприятии не работают полные тезки).

@ Внешний ключ - это атрибут таблицы, являющийся первичным ключом другой таблицы.

Например, атрибут "НОМЕР МОДЕЛИ" объекта АВТОМОБИЛЬ может быть внешним ключом по отношению к объекту "MODEL" (Модель автомобиля).

@ Запись данных - это совокупность значений связанных элементов данных.

На рис. 1.2. такими элементами данных являются уникальный ключ и наименование модели, рабочий объем, количество цилиндров и мощность двигателя. Например, одна из записей –“7 Voyager’96 3.8 Grand 3778 6 164,0” . Эта строка представляет собой значения, которые принимают элементы данных объекта МОДЕЛЬ АВТОМОБИЛЯ (MODEL). Записи хранятся на некотором носителе, в качестве которого может выступать человеческий мозг, лист бумаги, память ЭВМ, внешнее запоминающее устройство и т. д.

Рис.1.2. Записи данных объекта MODEL.

Каждая запись одной таблицы состоит из конечного (и одинакового!) числа полей , причем конкретное поле каждой записи одной таблицы может содержать данные только одного типа

@ Тип данных характеризует вид хранящихся данных.

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

@ Связь - это функциональная зависимость между сущностями.

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

Связи могу быть представлены пятью основными характеристиками:

Тип связи (идентифицирующая, не идентифицирующая)

Родительская сущность;

Дочерняя (зависимая) сущность;

Мощность связи (cordiality );

Допустимость пустых (null ) значений.

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

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

Мощность связи представляет собой отношение количества экземпляров родительской сущности к соответствующему количеству экземпляров дочерней сущности. Для любой связи, кроме неспецифической, эта связь записывается как 1:n .

@ Хранимые процедуры - это приложение (программа), объединяющее запросы и процедурную логику (операторы присваивания, логического ветвления и т. д.) и хранящееся в базе данных.

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

@ Правила позволяют вызывать выполнение заданных действий при изменении или добавлении данных в базу данных (БД) и тем самым контролировать истинность помещаемых в нее данных.

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

@ Ссылочная целостность - это обеспечение соответствия значения внешнего ключа экземпляра дочерней сущности значениям первичного ключа в родительской сущности.

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

@ Нормализация отношений - это процесс построения оптимальной структуры таблиц и связей в реляционной БД.

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

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

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

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

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

Система автоматизированной обработки данных основывается на использовании определенной модели данных или информационной модели. Модель данных отражает взаимосвязи между объектами.

2. Последовательность создания информационной модели

Процесс создания информационной модели начинается с определения концептуальных требований ряда пользователей (рис. 2.1). Концептуальные требования могут определяться и для некоторых задач (приложений), которые в ближайшее время реализовывать не планируется. Это может несколько повысить трудоемкость работы, однако поможет наиболее полно учесть все нюансы функциональности, требуемой для разрабатываемой системы, и снизит вероятность ее переделки в дальнейшем. Требования отдельных пользователей интегрируются в едином “обобщенном представлении”. Последнее называют концептуальной моделью.

@ Концептуальная модель представляет объекты и их взаимосвязи без указания способов их физического хранения.

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

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

@ Логическая модель отражает логические связи между элементами данных вне зависимости от их содержания и среде хранения.

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

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

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

Все актуальные требования предметной области и адекватные им "скрытые" требования на стадии проектирования должны найти свое отражение вконцептуальной модели. Конечно, нельзя предусмотреть все возможные варианты использования и изменения базы данных. Но в большинстве предметных областей такие основные данные, как объекты и их взаимосвязи, относительно стабильны. Меняются только информационные требования, то есть способы использования данных для получения информации.

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

3. Взаимосвязи в модели

Взаимосвязь выражает отображение или связь между двумя множествами данных. Различают взаимосвязи типа «один к одному », «один ко многим » и «многие ко многим ». В рассматриваемой задаче по автоматизации управления работой дилерапопродаже легковых автомобилей, если клиент производит заказ на покупку автомобиля впервые, осуществляется первичная регистрация его данных и сведений о сделанном заказе. Если же клиент производит заказ повторно, осуществляется регистрация только данного заказа. Вне зависимости от того, сколько раз данный клиент производил заказы, он имеет уникальный иденти­фикационный номер (уникальный ключ клиента). Информация о каждом клиенте включает наименование клиента, адрес, телефон, факс, фамилию, имя, отчество, признак юридического лица и примечание. Таким образом, атрибутами объекта КЛИЕНТ являются «УНИКАЛЬНЫЙ КЛЮЧ КЛИЕНТА», «НАИМЕНОВАНИЕ КЛИЕНТА», «АДРЕС КЛИЕНТА» и т. д. Следующий представляющий для нас интерес объект - МОДЕЛЬ АВТОМОБИЛЯ. Этот объект имеет атрибуты «УНИКАЛЬНЫЙ КЛЮЧ МОДЕЛИ», «НАИМЕНОВАНИЕ МОДЕЛИ» и т.д. Третий рассматриваемый объект - ЗАКАЗ. Его атрибутами являются «НОМЕР ЗАКАЗА», «КЛЮЧ КЛИЕНТА» и «КЛЮЧ МОДЕЛИ». И четвертый рассматриваемый объект - ПРОДАВЕЦ. Его атрибутами являются «УНИКАЛЬНЫЙ КЛЮЧ ПРОДАВЦА», «ИМЯ ПРОДАВЦА», «ФАМИЛИЯ» и «ОТЧЕСТВО».

Взаимосвязь «один к одному» (между двумя типами объектов)

Мысленно вернемся к временам планово-распределительной экономики. Допустим, в определенный момент времени один клиент может сделать только один заказ. В этом случае между объектами КЛИЕНТ и ЗАКАЗ устанавливается взаимосвязь «один к одному », обозначаемая одинарными стрелками, как это показано на рис. 2.2,а.

Рис. 2.2. Взаимосвязи между двумя объектами: а) «один к одному»; б) «один ко многим»; в) «многие ко многим»

Рис. 2.3. Взаимосвязь между данными при отношении «один к одному».

Взаимосвязь «один ко многим» (между двумя типами объектов).

В определенный момент времени один клиент может стать обладателем несколь­ких моделей автомобилей, при этом несколько клиентов не могут являться обладателями одного автомобиля. Взаимосвязь «один ко многим» можно обоз­начить с помощью одинарной стрелки в направлении к «одному» и двойной стрелки в направлении ко «многим», как это показано на рис. 2.2,б.

В этом случае одной записи данных первого объекта (его часто называют родительским или основным) будет соответствовать несколько записей второго объекта (дочернего или подчиненного). Взаимосвязь «один ко многим» очень распространена при разработке реляционных баз данных. В качестве родительского объекта часто выступает справочник, а в дочернем хранятся уникальные ключи для доступа к записям справочника. В нашем примере в качестве такого справочника можно представить объект КЛИЕНТ, в котором хранятся сведения о всех клиентах. При обращении к записи для определенного клиента нам доступен список всех покупок, которые он сделал и сведения о которых хранятся в объекте МОДЕЛЬ АВТОМОБИЛЯ, как это показано на рис. 2.4. В случае, если в дочернем объекте будут какие-то записи, для которых нет соответствующих записей в объекте КЛИЕНТ, то мы их не увидим. В этом случае говорят, что объект содержит потерянные (одинокие) записи. Это не допустимо, и в дальнейшем вы узнаете, как избегать подобных ситуаций.

Рис. 2.4. Взаимосвязь между данными при отношении «один ко многими».

Если мы будем просматривать записи объекта МОДЕЛЬ АВТОМОБИЛЯ, то в объекте КЛИЕНТ мы сможем получить данные о клиенте, купившем данный автомобиль (см. рис. 2.4). Обратите внимание, что для потерянных записей сведений о клиенте мы не получим.

Взаимосвязь «многие ко многими (между двумя типами объектов).

В рассматриваемом примере каждый продавец может обслуживать нескольких клиентов. С другой стороны, приобретая автомобили в различное время, каждый клиент вполне может быть обслужен различными продавцами. Между объектами КЛИЕНТ и ПРОДАВЕЦ существует взаимосвязь «многие ко многим». Такая взаимосвязь обозначается двойными стрелками, как это показано на рис. 2.2, в.

На рис. 2.5 приведена схема, по которой в этом случае будут взаимосвязаны данные. При просмотре данных в объекте КЛИЕНТ мы сможем узнать, какие продавцы обслуживали определенного клиента. Однако в объекте ПРОДАВЕЦ в этом случае нам придется завести несколько записей для каждого продавца. Каждая строчка будет соответствовать каждому обслуживанию продавцом кли­ента. При таком подходе мы столкнемся с серьезными проблемами. Например, не сможем ввести в объект ПРОДАВЕЦ уникальный ключ для каждого продав­ца, так как неизбежно один продавец будет обслуживать нескольких клиентов, и в этом случае у нас появится несколько записей для одного и того же продавца.

Рис. 2.5. Взаимосвязь между данными при отношении «многие ко многими

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

Рис. 2.6. Отображение взаимосвязи между данными при отношении «многие ко многим» с помощью промежуточного объекта

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

Взаимосвязь «один к одному» (между двумя атрибутами)

Мы предполагаем, что ключ (номер) клиента является его уникальным идентификатором, то есть он не изменяетсяпри последующих поступлениях заказов от данного клиента. Если наряду с номером клиента в базе данных хранится и другой его уникальный идентификатор (например, номер паспорта),то между такими двумя уникальными идентификаторами существует взаимосвязь «один к одному». На рис. 2.7,а эта взаимосвязь обозначается одинарными стрелками .

Взаимосвязь «один ко многим» (между двумя атрибутами)

Имя клиента и его номер существуют совместно. Клиентов с одинаковыми именами может быть много, но все они имеют различные номера. Каждому клиенту присваивается уникальный номер. Это означает, что данному номеру клиента соответствует только одно имя. Взаимосвязь «один ко многим» обозначается одинарной стрелкой в направлении к «одному» и двойной стрелкой в направлении ко «многим» (рис.2.7, б ).

Взаимосвязь «многие ко многим» (между двумя атрибутами)

Несколько клиентов с одинаковыми именами могли быть обслужены несколькими продавцами. Несколько продавцов с одинаковыми именами могли получить заказы от нескольких клиентов. Между атрибутами «имя клиента» и «имя продавца» существует взаимосвязь «многие ко многим». Мы обозначаем эту взаимосвязь двойными стрелками (рис. 2.7,в ).

а)

б)

в)

Рис. 2.7. Взаимосвязи между двумя атрибутами:
а) взаимосвязь «один к одному»; б) взаимосвязь «один ко многим » в) взаимосвязь «многие ко многим »

Типы моделей данных

Иерархическая и сетевая модели данных стали применяться в системах управления базами данных в начале 60-х годов. В начале 70-х годов была предложена реляционная модель данных. Эти три модели различаются в основном способами представления взаимосвязей между объектами.

Иерархическая модель данных строится по принципу иерархии типов объектов, то есть один тип объекта является главным, а остальные, находящиеся на низших уровнях иерархии, - подчиненными (рис. 2.8). Между главным и подчиненными объектами устанавливается взаимосвязь «один ко многим». Иными словами, для данного главного типа объекта существует несколько подчиненных типов объекта. В то же время для каждого экземпляра главного объекта может быть несколько экземпляров подчиненных типов объектов. Таким образом, взаимосвязи между объектами напоминают взаимосвязи в генеалогическом дереве за единственным исключением: для каждого порожденного (подчиненног o ) типа объекта может быть только один исходный (главный) тип объекта. На рис. 2.8 узлы и ветви образуют иерархическую древовидную структуру. Узел является совокупностью атрибутов, описывающих объект. Наивысший в иерархии узел называется корневым (это главный тип объекта). Корневой узел находится на первом уровне. Зависимые узлы (подчиненные типы объектов) находятся на втором, третьем и т. д. уровнях.

Рис. 2.8. Схема иерархической модели данных.

В сетевой модели данных понятия главного и подчиненных объектов несколько расширены. Любой объект может быть и главным и подчиненным (в сетевой модели главный объект обозначается термином “владелец набора”, а подчиненный – термином “член набора”). Один и тот же объект может одновременно выступать и в роли владельца, и в роли члена набора. Это означает, что каждый объект может участвовать в любом числе взаимосвязей. Схема сетевой модели приведена на рис.2.9.

Рис.2.9. Схема сетевой модели данных.

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

Рис. 2.10. Схема реляционной модели данных.

| Планирование уроков и материалы к урокам | 8 классы | Планирование уроков на учебный год | Табличные модели

Урок 12
Табличные модели

Табличные модели

Изучаемые вопросы:

Таблицы типа «объект-свойство».
- Таблица типа «объект-объект».
- Двоичные матрицы.

Таблицы типа «объект-свойство»

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

В качестве примера рассмотрим таблицу 2.1.

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

Таблица 2.1 - это информационная модель книжного фонда домашней библиотеки.

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

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

Таблицы 2.1 и 2.2 относятся к наиболее часто используемому типу таблиц. Их называют таблицами типа «объект-свойство» .

В одной строке такой таблицы содержится информация об одном объекте (книга в библиотеке или состояние погоды в 12-00 в данный день). Столбцы - отдельные характеристики (свойства) объектов.

Конечно, строки и столбцы в таблицах 2.1 и 2.2 можно поменять местами, повернув их на 90°. Иногда так и делают. Тогда строки будут соответствовать свойствам, а столбцы - объектам. Но чаще всего таблицы строят так, чтобы строк в них было больше, чем столбцов. Как правило, объектов больше, чем свойств.

Основы информационных систем. Базы данных.

План.

1. Основные понятия.

2. Классификация баз данных.

3. Модели данных.

4. Информационные объекты и связи.

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

6. Состав файла БД. Архитектура СУБД.

7. Связывание таблиц. Целостность данных.

8. Виды запросов. Структура запросов.

Основные понятия.

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

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

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

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

Для облегчения обработки информации создаются информационные системы. Информационная система представляет собой аппаратно-программный комплекс, обеспечивающий выполнение следующих функций:

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

· надежное хранение и защита данных во внешней памяти вычислительной системы;

· дополнение, удаление, изменение данных;

· сортировка, выборка данных по запросам пользователей;

· выполнение специфических для данной предметной области преобразований информации;

· предоставление пользователям удобного интерфейса; обобщение данных и составление отчетов.

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

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

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

Классификация баз данных.

По технологии обработки данных БД подразделяются на централизованные и распределенные.

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

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

По способу доступа к данным БД распределяются на локальный и удаленный (сетевой) доступ.

Локальный доступ предполагает, что СУБД обрабатывает БД, которая хранится на той же вычислительной системе.

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

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

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

Модели данных.

Для реализаций основных функций в ИС используются различные принципы описания данных. Ядром любой БД является модель представления данных .

Модель данных определяет логическую структуру хранимых в базе данных (т.е. введение каких-то соглашений о способах представления данных) и взаимосвязи между ними.

К основным моделям представления данных относятся:

· Иерархическая

· Сетевая

· Реляционная

· Постреляционная

· Многомерная

· Объектно-ориентированная

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

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

Каждая реляционная таблица должна обладать следующими свойствами:

· один элемент таблицы - один элемент данных;

· каждый столбец таблицы содержит однородные по типу данные (целочисленный, числовой, текстовый, и т.д.);

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

· число столбцов задается при создании таблицы;

· порядок записей в отношении может быть произвольным;

· записи не должны повторяться;

· количество записей в отношении не ограничено.

Объекты, их взаимосвязи и отношения представлены в виде таблиц . Формальное построение таблиц связано с фундаментальным понятием отношение (термин реляционная исходит от английского слова relation - отношение).

Для заданных произвольных конечных множеств М 1 , М 2 , ..., M N множество всевозможных наборов вида (μ 1 , μ 2 , …, μ Ν), где μ 1 Є М 1 , μ 2 Є М 2 , …, μ Ν Є M N называют их декартовым произведением М 1 ×М 2 ×...×M N . Отношением R , определенным на множестве М 1 , М 2 , ..., M N , называется подмножество декартова произведения М 1 ×М 2 ×...×M N . При этом множества М 1 , М 2 , ..., M N называются доменами отношения, а элементы декартова произведения - кортежами отношения. Число N определяет степень отношения, количество кортежей - его мощность .

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

Строка заголовков называется схемой отношения .

Например , схема отношения СТУДЕНТ может быть следующей:

СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА), здесь СТУДЕНТ - отношение, а ФАМИЛИЯ, ИМЯ и т.д. - атрибуты.

В отношении каждый конкретный экземпляр сущности представляется строкой, которая называется кортежем (или записью) .

Следующая таблица представляет отношение СТУДЕНТ

Первичным ключом отношения называется поле или группа полей, однозначно определяющие запись. В отношении СТУДЕНТ первичным ключом может быть поле ФАМИЛИЯ, если во всем с нет однофамильцев - это будет простой ключ. Если есть однофамильцы, то совокупность полей - фамилия, имя, отчество - создадут составной первичный ключ. На практике обычно в качестве ключевого выбирают поле, в котором совпадения заведомо исключены.

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

Свойства первичного ключа:

· уникальность - в таблице может быть назначен только один первичный ключ, у составного ключа поля могут повторяться, но не все;

· неизбыточность - не должно быть полей, которые, будучи удаленными из первичного ключа, не нарушат его уникальность;

· в состав первичного ключа не должны входить поля типа, комментарий и графическое.

Чтобы избежать повторяющихся записей, приходят к связыванию таблиц. Например, если в отношении СТУДЕНТ надо описать вуз, в котором он обучается, то, на первый взгляд, можно было бы включить в отношение следующие поля СТУДЕНТ (ФАМИЛИЯ ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА, НАЗВАНИЕ вуза, АДРЕС). Но при заполнении такой таблицы для каждого студента придется указывать довольно длинное наименование вуза и его адрес, что неудобно. Более того, любая незначительная ошибка во вводе этих полей приведет к нарушению непротиворечивости базы данных. Например, ошибка в адресе вуза приведет к тому, что в БД появятся два вуза с одинаковым наименованием и разными адресами. Поступают в таком случае так: в отношение СТУДЕНТ вводят поле «код вуза» (целое число) и добавляют еще одно отношение ВУЗ (код вуза, название, адрес). Тогда отношения СТУДЕНТ и ВУЗ при этом будут связаны по полю «код вуза».

СТУДЕНТ (ФАМИЛИЯ, ИМЯ, ОТЧЕСТВО, ФАКУЛЬТЕТ, КУРС, ГРУППА, КОД вуза)

ВУЗ (КОД вуза, НАЗВАНИЕ, АДРЕС, ТЕЛЕФОН)

При работе с такими таблицами повторяться могут только данные в поле «КОД вуза», а все необходимые сведения о вузе можно взять из отношения ВУЗ. Заметим при этом, что ввод в поле «КОД вуза» целого числа, вместо длинного названия, принесет гораздо меньше ошибок. В отношении ВУЗ поле «КОД вуза» будет первичным ключом, а в отношении СТУДЕНТ поле «КОД вуза» будет внешним ключом.

Для связи реляционных таблиц необходимо ввести в обе таблицы одинаковые по типу поля, по которым определится связь между записями обеих таблиц. Связи бывают нескольких типов «один к одному», «один ко многим», «многие ко многим». В вышеприведенном примере была установлена связь «один ко многим», т.е. одной записи в таблице ВУЗ соответствуют многие записи в таблице СТУДЕНТ.

Информационные объекты и связи.

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

Пример . Информационный объект СТУДЕНТ имеет реквизитный состав: номер (номер зачетной книжки - ключевой реквизит), фамилия , имя , отчество , дата рождения , код места обучения . Информационный объект ЛИЧНОЕ ДЕЛО: номер студента , домашний адрес , номер аттестата о среднем образовании , семейное положение , дети . Информационный объект МЕСТО ОБУЧЕНИЯ включает реквизитъг, код (ключевой реквизит), наименование вуза , факультет , группа . Информационный объект ПРЕПОДАВАТЕЛЬ: код (ключевой реквизит), кафедра , фамилия , имя , отчество , ученая степень , ученое звание , должность .

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

Связь один к одному определяет соответствие одному экземпляру информационного объекта X не более одного экземпляра информационного объекта Y, и наоборот.

Пример . Информационные объекты СТУДЕНТ и ЛИЧНОЕ ДЕЛО будут связаны отношением один к одному. Каждый студент имеет определенные уникальные данные в личном деле.

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

Пример . Между информационными объектами МЕСТО ОБУЧЕНИЯ и СТУДЕНТ необходимо установить связь один ко многим. Одно и то же место обучения может многократно повторяться для различных студентов.

Связь многие ко многим предполагает соответствие одному экземпляру информационного объекта X любое количество экземпляров объекта Y, и наоборот.

Пример . Информационные объекты СТУДЕНТ и ПРЕПОДАВАТЕЛЬ имеют связь многие ко многим. Каждый студент обучается у множества преподавателей, а каждый преподаватель учит множество студентов.

В Access можно задать три вида связей между таблицами: один ко многим , многие ко многим и один к одному . Связь один ко многим является наиболее часто используемым типом связи между таблицами. Связи многие ко многим реализуется только с помощью третьей (связующей) таблицы, ключ которой состоит из, по крайней мере, двух полей, одно из которых является общим с табли­цей X, а другое - общим с таблицей Y. Связь один к одному используют не очень часто, поскольку такие данные могут быть помещены в одну таблицу. Связь с отношением один к одному используют для разделения очень широких таблиц, для отделения части таблицы по соображениям защиты, а также для сохранения сведений, относящихся к подмножеству записей в главной таблице.

Похожая информация.

При разработке базы данных сначала исследуется предметная область (например, «Университет»). В ней выделяются основные объекты. Они могут быть реальными («Студент») или абстрактными («Дисциплина»). Каждый объект характеризуется набором свойств – атрибутов объекта (поля данных) . Для каждого объекта атрибуты заполняются определенными значениями. Атрибуты могут быть простыми и ключевыми.

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

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

a) 1:1 ("один к одному») – каждому экземпляру объекта А соответствует только один экземпляр объекта В и наоборот (рисунок 17).

Рисунок 17 – Связь «один к одному»

b) 1:М («один ко многим») – каждому экземпляру объекта А может соответствовать 0, 1 или несколько экземпляров объекта В, однако каждому экземпляру объекта В соответствует только 1 экземпляр объекта А (рисунок 18).

Рисунок 18 – Связь «один ко многим»

c) М:М («многие ко многим») – каждому экземпляру объекта А соответствует 0, 1 или несколько экземпляров объекта В и наоборот (рисунок 19).

Рисунок 19 - Связь «многие ко многим»

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

Отношения

Объект предметной области может быть представлен в виде таблицы-отношения – таблицы особого рода, у которой:

· каждая строка содержит информацию об одном экземпляре объекта (строка отношения - кортеж );

· все столбцы однородные, то есть все элементы в столбце имеют одинаковый тип и длину, имеют имя и содержат информацию об отдельном атрибуте объекта;

· каждый элемент представляет собой один элемент данных об объекте;

· все строки и столбцы уникальны (нет повторений);

· в таблицах нет пустых ячеек.

Базы данных, основанные на таблицах-отношениях, называются реляционными (relation - отношение). Набор отношений (таблиц) используется в БД для хранения информации об объектах реального мира и моделирования связей между ними. Например, для хранения объекта «студент» используют отношение СТУДЕНТ , в котором свойства объекта располагаются в столбцах таблицы, являющихся атрибутами объекта (таблица 8):

Таблица 8 – Отношение СТУДЕНТ

Список имен атрибутов отношения называется схемой отношения . Схему отношения СТУДЕНТ можно записать так:СТУДЕНТ = (Фамилия, Возраст, Группа).

Реляционная БД – набор взаимосвязанных отношений. Каждое отношение (таблица) в ЭВМ представляется в виде файла записей.

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

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

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

Существует несколько нормальных форм :

1-я нормальная форма. Отношение считается находящимся в первой нормальной форме, если все его атрибуты – неделимые (простые). К примеру, приведенное ниже на рисунке 20 отношение не нормализовано, поскольку содержит сложный атрибут Спорт . Чтобы привести это отношение к нормализованному виду, нужно избавиться от этого сложного атрибута.

Рисунок 20 – Приведение к первой нормальной форме

В полученном отношении ключ является составным, состоящим из атрибутов Фамилия и Вид спорта .

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

Например, в отношении ВЕДОМОСТЬ (рисунок 21), имеющем составной ключ «Студент, Дисциплина», атрибут Лектор зависит только от Дисциплины , а не от всего ключа. Это отношение можно нормализовать, «разбив» его на два отношения УСПЕВАЕМОСТЬ и ПРЕПОДАВАТЕЛЬ :

ВЕДОМОСТЬ = (Студент, Дисциплина, Лектор, Оценка)

УСПЕВАЕМОСТЬ = (Студент, Дисциплина , Оценка) ПРЕПОДАВАТЕЛЬ = (Дисциплина , Лектор)

Рисунок 21 – Приведение ко второй нормальной форме

3-я нормальная форма. Отношение считается находящимся в третьей нормальной форме, если устранены зависимости между не ключевыми атрибутами (транзитивные зависимости). Например, в отношении ПРЕДМЕТ = (Название, Лектор, Кафедра, Телефон) не ключевой атрибут Телефон зависит от не ключевого атрибута Кафедра .

Для устранения транзитивной зависимости необходимо «расщепить» исходное отношение на два ДИСЦИПЛИНА = (Название , Лектор, Кафедра) и ДАННЫЕ КАФЕДРЫ = (Кафедра , Телефон).

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

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

Рисунок 22 – Модель фирмы

На основании инфологической модели разрабатывается модель данных, которая дает описание логической структуры базы данных на языке описания данных (ЯОД), – даталогическая модель (ДМ) .

Для привязки ДМ к среде хранения используется модель данных физического уровня – физическая модель (ФМ). На этом этапе физического проектирования базы данных осуществляется выбор типа носителя, разрабатывается формат хранимых записей и проектируются методы доступа к данным.

СУБД

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

1) запись (заполнение базы данных);

2) просмотр;

3) редактирование (добавление, удаление, исправление);

4) выборка (запросы, отчеты).

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

По технологии решения задач, выполняемых СУБД, базы данных можно разделить на два вида:

Централизованная БД (хранится целиком на ВЗУ одной вычислительной системы и, если система входит в состав сети, то возможен доступ к этой БД других систем);

Распределенная БД (состоит из нескольких, иногда пересекающихся или дублирующих друг друга БД, хранящихся на ВЗУ разных узлов сети).

СУБД предоставляет доступ к данным БД двумя способами:

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

Удаленный доступ (это обращение к БД, которая хранится на одном из узлов сети).

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

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

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

Языковые средства обеспечивают взаимодействие пользователя с базой данных. К ним относятся:

• языки манипулирования данными (ЯМД) – языки запросов к БД, представляющие собой систему команд для работы с данными (выборка, запрос, вставка, удаление и т.п.);
• языки определения данных (ЯОД) – языки, предназначенные для создания схемы базы данных (описания типов данных, структуры базы, взаимодействия и связей между элементами).

Рисунок 22 - Схема взаимодействия пользователя с базой данных

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

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

При выборе информационных объектов необходимо ответить на ряд вопросов:

1. На какие таблицы можно разбить данные, подлежащие хранению в БД?

2. Какое имя можно присвоить каждой таблице?

3. Какие наиболее интересные характеристики (с точки зрения пользователя) можно выделить?

4. Какие имена можно присвоить выбранным характеристикам?

В нашем случае предполагается завести следующие таблицы (рис 4):

Выделим связи между информационными объектами (рис.5)

В ходе этого процесса необходимо ответить на следующие вопросы:

1. Какие типы связей между информационными объектами?

2. Какое имя можно присвоить каждому типу связей?

3. Каковы возможные типы связей, которые могут быть использованы впоследствии?

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

1. Какова область значений для числовых характеристик?

2. Каковы функциональные зависимости между характеристиками одного информационного объекта?

3. Какой тип отображения соответствует каждому типу связей?

При проектировании БД существуют взаимосвязи между информационными объектами трех типов: «один к одному», «один ко многим», «многие ко многим» (рис.6).

Например:

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

В простых случаях для построения концептуальной схемы используют традиционные методы агрегации и обобщения. При агрегации объединяются информационные объекты (элементы данных) в один в соответствии с семантическими связями между объектами. Например, урок истории в 10 «а» классе проводится в кабинете №7, начало в 9-30. Методом агрегации создаем информационный объект (сущность) РАСПИСАНИЕ со следующими атрибутами: «класс», «предмет», «кабинет», «время». При обобщении информационные объекты (элементы данных) объединяются в родовой объект (рис.7):

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

Модели «сущность-связь», дающие возможность представлять структуру и ограничения реального мира, а затем трансформировать их в соответствии с возможностями промышленных СУБД, являются весьма распространенными.

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

Тип сущности - ученик

Экземпляр сущности - Иванов, Петров, Сидоров и др.

В нашем примере Школа, Класс, Предметы, Ученики, Учителя, Оценки – сущности. Проанализируем связи между сущностями (рис.8).

Теперь можно перейти к проектированию информационной (концептуальной) схемы БД (атрибуты сущностей на диаграмме не показаны) (рис.9).

принадлежит		Школа
Класс		Учится		Ученик
работает				изучает
Учитель		Преподает		Предмет
			экзамен
			Ведомость

Логическое проектирование

Логическое проектирование представляет собой необходимый этап при создании БД. Основной задачей логического проектирования является разработка логической схемы, ориентированной на выбранную систему управления базами данных. Процесс логического проектирования состоит из следующих этапов:

1. Выбор конкретной СУБД;

2. Отображение концептуальной схемы на логическую схему;

3. Выбор языка манипулирования данными.

Выбор конкретной СУБД

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

Конструирование баз данных на основе реляционной модели имеет ряд важных преимуществ перед другими моделями

· Независимость логической структуры от физического и пользовательского представления.

· Гибкость структуры базы данных – конструктивные решения не ограничивают возможности разработчика БД выполнять в будущем самые разнообразные запросы.

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